You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Restricting the node indices to a specific type has worked well for us up until now, since we always reference nodes in the same internal base hugr (see #1926). This breaks down with more exotic implementations of HugrView that needs to track additional data on each index (see CQCL/tket2#778).
This proposal addresses that by making the Node index generic, defaulting to the current Node type for all the current impls. Citing @lmondada:
Node becomes an associated type in HugrView. The change will be verbose but should not impact users much. It shouldn't make our code significantly more verbose either, given that we can add all the required type bounds on the trait definition (Copy, Ord, Hash and conversions to/from portgraph).
The text was updated successfully, but these errors were encountered:
closes#1927
Yey, this is a fun one 🫠
This makes `HugrView` general over the `Node` type. Note that `HugrMut`
and all operations that mutate hugrs still only act on the node type
`Node`.
I suggest once this is merged in that we add a `.git-blame-ignore-revs`
file to simplify future git blames:
```
# Commits to be ignored by git blame
# Add Node associated type to HugrView (large mechanical change)
<commit of this PR on main>
```
BREAKING CHANGE: `HugrView` now has a `Node` associated type. Make your
code generic over the node type where you can, replacing `Node` with
`H::Node`. Otherwise, use the type bound `H: HugrView<Node = Node>`.
Restricting the node indices to a specific type has worked well for us up until now, since we always reference nodes in the same internal base hugr (see #1926). This breaks down with more exotic implementations of
HugrView
that needs to track additional data on each index (see CQCL/tket2#778).This proposal addresses that by making the
Node
index generic, defaulting to the currentNode
type for all the current impls. Citing @lmondada:The text was updated successfully, but these errors were encountered: