Summary

AnnotatedOperations allow to define a "controlled" version of a gate when a circuit is being constructed, without having to eagerly synthesize the gate in the process. The actual synthesis is left to the transpiler (and specifically to the HighLevelSynthesis transpiler pass). This offers at least two benefits:

• We can first define a circuit with controlled parameterized gates, and later bind the parameters and transpile the circuit.
• We can use additional optimizations when transpiling a circuit and in particular efficiently handle the circuit in Improve synthesis of controlled circuits with controlled gates within #13566.

The control method for Gates and QuantumCircuits already accepts the argument annotated which can be either False, True or None, with roughly the following semantics:

• If False, the annotated version of the gate is not constructed, with the only exception that an annotated=False-controlled version of an AnnotatedOperation is an AnnotatedOperation as well.
• If True, the annotated operation is constructed, except for gates that implement their own control method, thus an annotated=True-controlled version of an XGate will produce either a CX-Gate, a CCX-Gate, or an MCX-Gate.
• If None, we attempt to construct an annotated=False-version, but if this fails, such as when the gate is parameterized, we create the annotated=True-version.

In the above, None is the default.

In addition, for backward compatibility (at the time), when a QuantumCircuit is converted to a Gate using the to_gate method, the argument annotated is set to False. Unfortunately, this means that when constructing hierarchical circuits that involve controlled subcircuits, the subcircuits are typically not annotated, preventing potential transpiler optimizations. For example this is the case for the older version of circuits in the circuit library, though this is somewhat improved for the new gate classes when control(annotated=True) is explicitly specified. On the other hand, most of the user circuit are not constructed using annotated=True.

The suggestion here is to change the default behavior to construct annotated versions of a gate (unless the gate implements a custom control method). This is a breaking API change, and in particular if someone now writes my_controlled_custom_gate = my_custom_gate.control(3), the my_controlled_custom_gate will no longer be an instance of ControlledGate. I don't if this can break a lot of user code potentially depend on this isinstance check. In addition, the my_controlled_custom_gate will not have a definition available, one would need to use transpile/HighLevelSynthesis to obtain one.

I would like to discuss if we can add this breaking change to 2.0 or possibly to a later release, and what the migration path for the users should be. Comments are highly welcome.

This PR shows that the number of factual changes within Qiskit is very small: the main difference comes up in visualization, where the name of a ControlledGate-version of a gate is drawn with all letters lowercased, while the name of an AnnotatedOperation-version of a gate is drawn with first letter uppercased (compare "ghz" and "Ghz"); and also the annotated-control SWAP gate is drawn differently.