Do we bind to qubits too early?

[daxfohl]

When creating a circuit, we hard-bind that circuit to qubits. Should we do that later, at simulation/run time instead?

The problems with binding to qubits are

• Circuits are less reusable. Have to recreate the circuit to run on devices that have different qubit topologies or dimensions.
• Makes subcircuits awkward to use, in that they require qubit mappings.
• There are places in our code where we make throwaway line qubits (decomposing gates, etc), which makes that code less efficient harder to understand.
• Increases learning curve. (I personally struggled for a while before figuring out that qubit identities didn't matter, just the values they contain).
• All tests have to start out with q1, q2, q3, q4 = cirq.LineQubit.range(4).

I'd propose just using indices everywhere, until you want to put it on a device or run through a simulator, which would have an optional parameter for qubit-index mapping.

• Lower learning curve
• Circuit definitions can be reused in different topologies, different qubit dimensions.
• Subcircuits are easier to use. Say we defined SWAP as a subcircuit of 3 CNOTs. Compare SWAP(2, 4) with SWAP.with_qubit_mapping({q2: cirq.LineQubit(0), q4: cirq.LineQubit(1)})
• Unit tests are simpler to write, and a small perf boost for long narrow circuits since we don't have to do all the dictionary lookups.

Additionally this would make the Operation/Gate dichotomy obsolete. (Working on operation-to-gate conversions was the source of this thought). Everything could be defined as gates at that point, and simulators would just use (gate, indices) tuples. We wouldn't need Operation at all. This would positively impact gatesets ease-of-use and implementation, simplify the implementation and edge cases of our protocols that work with both classes, simplify simulators, etc. That would lead to a big reduction in the amount of code, edge cases, and tests. It would also close a few usability issues in this repo as no-longer-applies.

Cons: Ginormous breaking change. Perhaps we could "work toward" this in some less breaky way though?

[daxfohl]

I fiddled with this and just don't see a way to do it in sensible stages that don't require some major changes. The advantages this change would provide are nice, but nothing earth shattering. I'm closing this unless I come up with something that's a little lower hanging as a first step.

[daxfohl]

Notably, qid_shape is early-bound with verifications almost everywhere. To late-bind that, it requires passing through so many functions. Like, even the unitary protocol would now require a qid_shape argument for varadic gates. Measurements, even qasm output would all require the same. Just, IDK, I don't see an easy path from here to there.

[vtomole]

I'd propose just using indices everywhere

If I recall, @Strilanc said that he wished he did this from the beginning but it's too late now.

[daxfohl]

There is perhaps an opportunity to backdoor this. #4725 provides a CircuitGate, that is the gate for a CircuitOperation. That gate does use indices rather than qubits in its definition. So conceivably we could add that, and start using CircuitGates as the starting point to define circuits, only applying qubits at the end.

One issue is that CircuitGtae doesn't support a Moment structure. There are other things in the linked PR that would need resolved as well. I closed the PR because I don't think the ROI is there, but if we do want to start using indices instead of qubits, that would be a place to start.