Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: Nonempty #902

Closed
wants to merge 4 commits into from
Closed

refactor: Nonempty #902

wants to merge 4 commits into from

Conversation

Cobord
Copy link
Contributor

@Cobord Cobord commented Mar 29, 2024

Replacements and SiblingSubgraph have nonempty vecs upon construction. Attempting to create them with empty vecs gives errors (InvalidSubgraph::EmptySubgraph) so following "illegal state unrepresentable".

Copy link

codecov bot commented Mar 29, 2024

Codecov Report

Attention: Patch coverage is 85.00000% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 85.56%. Comparing base (a2e4d05) to head (e689e91).

❗ Current head e689e91 differs from pull request most recent head 5d408d6. Consider uploading reports for the commit 5d408d6 to get more accurate results

Files Patch % Lines
quantinuum-hugr/src/hugr/views/sibling_subgraph.rs 78.57% 0 Missing and 3 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #902      +/-   ##
==========================================
- Coverage   85.63%   85.56%   -0.08%     
==========================================
  Files          78       78              
  Lines       14444    14415      -29     
  Branches    14444    14415      -29     
==========================================
- Hits        12369    12334      -35     
- Misses       1436     1443       +7     
+ Partials      639      638       -1     
Flag Coverage Δ
rust 85.56% <85.00%> (-0.08%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Cobord Cobord marked this pull request as ready for review April 2, 2024 17:27
@aborgna-q aborgna-q self-requested a review April 3, 2024 12:31
Comment on lines +271 to 272
pub fn nodes(&self) -> &NonEmpty<Node> {
&self.nodes
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to leave the NonEmpty out of the public interface here,

Suggested change
pub fn nodes(&self) -> &NonEmpty<Node> {
&self.nodes
pub fn nodes<'a>(&'a self) -> impl Iterator<Item = &'a Node> + &'a {
self.nodes.iter()

that breaks some code, you'll need some collect_vecs around (which implies allocating new arrays :/).

So something like

let portgraph: NodeFiltered<_, NodeFilter<Vec<Node>>, Vec<Node>> =
    NodeFiltered::new_node_filtered(
        other.portgraph(),
        |node, ctx| ctx.contains(&node.into()),
        subgraph.nodes().cloned().collect_vec(),
    );

in HugrMut::insert_subgraph.

@@ -59,7 +59,7 @@ pub struct Replacement {
/// These must all have a common parent (i.e. be siblings). Called "S" in the spec.
/// Must be non-empty - otherwise there is no parent under which to place [Self::replacement],
/// and there would be no possible [Self::mu_inp], [Self::mu_out] or [Self::adoptions].
pub removal: Vec<Node>,
pub removal: NonEmpty<Node>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires every dependent to add a direct dependency on NonEmpty. Although it's nice to statically check this internally, i'd prefer the external interface be left more generic.

Adding a Replacement::try_new(removel: Vec<Node>, ...) could help with this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair enough

@aborgna-q
Copy link
Collaborator

aborgna-q commented May 1, 2024

Hey, we'll close this for now as it requires exposing transitive dependencies in the public API.
This change would improve the static compiler checks, but it's not worth the added complexity.

Thanks nonetheless for suggesting the change :)

@aborgna-q aborgna-q closed this May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants