Draft: StrictCompositeComponent

[gpeairs]

This is a draft of a proposed v2.0 CompositeComponent change, which would be introduced in v1 as StrictCompositeComponent. The main idea is to allow the type of every node in the graph to be derived from the composite component type. Opening a PR now for visibility/discussion.

With current CompositeComponents, anything can happen in _build_subcomponents or _graph!. Two instances of the same type can have different subcomponent types, different numbers of nodes, different node IDs, different hook mappings, all of which can only be determined at runtime. This is annoying in several places, for example: map_hooks keys on node index, which doesn't have static meaning and depends on the order the graph is built up; ParameterSet addressing has no guarantees about subcomponent namespaces; type-level validation in general is impossible.

So in more detail, we want:

1. Subcomponent "slots" (component name and type) derived from Type{MyComp} alone
2. Node IDs derivable from Type{MyComp} alone (separate from slots so you can have one subcomponent in multiple nodes)
3. map_hooks keyed by node ID
4. PS addressing targets slot names, guaranteed to resolve
5. Default _build_subcomponents derivable from declared slots + parameter filtering/forwarding

Path subcomponents can still be used, but they have to be built up in _graph!. Route subcomponents are trickier, they probably have to be added in _graph!, which is possible (weakening some guarantees, but not so harmful in this case). Templates are still possible (with fixed types) -- just another kind of parameter forwarding -- but maybe this is also an opportunity to better formalize them.

I can imagine cases where users want to customize the node ID or component name as a parameter (for compatibility with some changing external schema). Maybe that can done with a variant, although variant composites still have issues with ParameterSet.

You can have variable subcomponent types if you use type parameters (see ExampleStrictRectangleTransmon{JunctionType}).

We could go one step further and require that edges be specified at the type level (call that "DeclarativeCompositeComponent"), so that _graph! is also fully determined. This is maybe too restrictive to require in general -- harder to work with Paths, edges created with attach!, or routes, although maybe we could find a way.

[codecov]

Codecov Report

❌ Patch coverage is 97.79412% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...atics/ExamplePDK/components/Transmons/Transmons.jl	77.77%	2 Missing ⚠️
...hematics/components/strict_composite_components.jl	99.14%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[gpeairs]

Minor things so I don't forget

• Implicitly forwarding filtered parameters is probably too aggressive (weaker point: also if the user filters explicitly we don't need the duplicate quiet version of filter_parameters); I would at least make templates special to make up for it
• Still needs to thread PS through composite variants and composite subcomponents
• Better tests for nesting, flattening
• Don't export so much
• Fix strict transmon docstring
• Fallback hook names may produce collisions
• Maybe still allow custom _build_subcomponents and in that case just use declared slots/nodes to validate