Remove implicit assumption that Operations have Gates

Is your feature request related to a use case or problem? Please describe.

The Operation has a gate property which is frequently used to identify its type. However, not all Operations are GateOperations, meaning that this field is not always populated.

Until recently this has been a relatively minor problem, since the vast majority of Operations are GateOperations. However, with the introduction of CircuitOperation (#3580) this issue is becoming more pronounced.

Related issue: #3235.

Describe the solution you’d like

Remove gate field in Operation and replace with a get_operator abstract method, defined in implementations. This will require deprecating the field and replacing it across the Cirq repo.

[optional] Describe alternatives/workarounds you’ve considered

• Add local fixes to sections of code that need to recognize CircuitOperation, and leave the rest unchanged.
  • Issue: eventually, CircuitOperation should be supported everywhere.
• Make Circuit a subclass of Gate, with CircuitOperations containing CircuitGates
  • Rejected during review (#3509): treating circuits as gates introduces undesirable behavior

What is the urgency from your perspective for this issue? Is it blocking important work?

P1 - I need this no later than the next release (end of quarter)

This confounds work on CircuitOperations, as they do not have a value in their gate field. Continuing work in that space without resolving this issue requires workarounds which will increase the cost of an eventual fix.

[95-martin-orion]

@daxfohl: Subcircuits as they are implemented today are just as “instantaneous” as any other operation. Consider this circuit:

a, b, = cirq.LineQubit.range(2)
circuit = cirq.Circuit(
  cirq.Moment(
    cirq.H(a),
    cirq.H(b),
  ),
  cirq.Moment(
    cirq.measure(a, key='m1'),
    cirq.CircuitOperation(
      cirq.FrozenCircuit(
        cirq.Moment(cirq.T(b)),
        cirq.Moment(cirq.H(b)),
        cirq.Moment(cirq.X(b)**0.5),
      )
    ),
  ),
  cirq.Moment(
    cirq.X(a),
    cirq.measure(b, key='m2'),
  ),
)

There are two things to note about the second moment of the top-level circuit:

• The CircuitOperation runs entirely within the second moment, alongside the measurement. It will not “spill over” into the third moment - the moments it contains are “sub-moments” of the second top-level moment, in a sense.
• On many types of quantum hardware, the measure operation will actually take longer than the CircuitOperation, despite being a single operation. Hardware durations of operations can vary considerably.

(These items are true even without explicit cirq.Moments wrapping each moment; I just added those to clarify the structure.)

For more details on why CircuitOperation was implemented as it is, you can read the original RFC here: https://tinyurl.com/cirq-circuitoperation-rfc.

[mpharrigan]

• Violates some software engineering principles
• Changing it would be too hard
• @95-martin-orion says there’s more tools now so he’s less annoyed.

Short term solution: #3893 Long term solution: #2536