quantumlib
Deprecate `TaggedOperations`
Description of the issue
Moved tags to the Operation class
Cirq version master version
Note I tried this a while back and it's hugely invasive. For example TaggedOperation intercepts several protocol methods like diagram_info and resolve_params, and adorns them with its own behavior before forwarding inward. If it's in the base class, this behavior is impossible, as the subop class's protocol implementation simply overrides it. All these protocol methods need to be changed to abstract/virtual methods of a different name, and have the base class's protocol call them, or something.
Also since op classes aren't dataclasses, we need to bring in the copy module to implement with_tags. Which, we do use copy elsewhere so maybe that's not as much of a problem, but my impression is that people with a strong Python background tend to be wary of depending on copy. Also the scale on which this would use copy would extend to all subclasses of Operation, including custom ops, which is much more than anything we currently use it for.
I think this is worth another discussion, especially given Dax's comments on how this is not as straightforward as it seems on face value.
One option that may actually be easier is if we go all in and change all existing operations to gates. I've done a few of those for https://github.com/quantumlib/Cirq/issues/4683. The ones remaining are those from https://github.com/quantumlib/Cirq/issues/2626 (PauliString, QFT), and the higher level ones like CircuitOperation and ClassicallyControlledOperation. (POC for the former was working at https://github.com/quantumlib/Cirq/pull/4725).
If we do that, then GateOperation is all that's left. No inheritance hierarchy or anything. So we can simply add the tag to that class and be done.
Still a lot of work to get to this point but I think it would result in a nice design. @95-martin-orion @tanujkhattar
This is a large design issue and would require a considerable thought. Given that we are already past the threshold of considering large design items for Cirq 1.0, we should mark it as post 1.0 and work on it for Cirq 2.0.
Discussed in Cirq Cynq 2025-10-15:
Concluded this was too much effort without clear benefit. If things were being designed from scratch now, it might be worth doing, but now things too entangled with the current scheme.
