`ClassicallyControlledOperation` breaks assumption that disjoint operations commute.

Description of the issue

ClassicallyControlledOperation was recently introduced to enable classical controls in Cirq. The method takes as input a sub_operation and a list of conditions, which correspond to measurement keys of previous measurements.

https://github.com/quantumlib/Cirq/blob/6119620178d7d1d0f11c5f2b73998fb2b66fcd2d/cirq-core/cirq/ops/classically_controlled_operation.py#L49-L53

The operations is implemented in a way that the qubit set it acts on remains the same as the set of qubits of the underlying operation to be controlled, and the operation “assumes” that measurements corresponding to the conditions have already occurred to the left of the operation.

This is a big problem for transformers because this introduces an implicit dependency between a measurement operation and a classically controlled operation which makes use of these measurement results.

How to reproduce the issue

>>> import cirq
>>> q = cirq.LineQubit.range(2)
>>> c = cirq.Circuit(cirq.H(q[0]), cirq.measure(q[0], key='m'), cirq.X(q[1]).with_classical_controls('m'))
>>> print(c)
0: ───H───M───────
          ║
1: ───────╫───X───
          ║   ║
m: ═══════@═══^═══
>>> cirq.SynchronizeTerminalMeasurements().optimize_circuit(c)
>>> print(c)
0: ───H───────────M───
                  ║
1: ───────────X───╫───
              ║   ║
m: ═══════════^═══@═══
>>> cirq.Simulator().simulate(c)
ValueError: Measurement key m missing when testing classical control

Cirq version

0.14.0.dev

cc @95-martin-orion @daxfohl

[daxfohl]

We already have logic in circuit.append to ensure that when you append a control, it does not fall back beyond the measurement that creates the key. https://github.com/quantumlib/Cirq/blob/39ce4f0e7c79479913491f9b434461c9397eb677/cirq-core/cirq/circuits/circuit.py#L1967

I don’t think it would be good for usability if we require users to state which qubits correspond to the measurement key when instantiating the classically controlled operation. Maybe there’d be some way to hack this in such that there’s a lookup somewhere that we can get the qubits corresponding to the key, and can avoid the user needing to specify it manually, but nothing comes to mind. Also the latter solution won’t work once we allow repeated measurement keys, as each measurement could correspond to different qubits (potentially, depending on the design).

So, I think the best solution is to reuse the logic from Circuit.append if possible.

[daxfohl]

Seems to be an issue with CI, something unrelated in Pandas is broken for that PR but the test passes locally.