What about non-default decompose?

[kevinsung]

Presumably, CompositeGate implements default_decompose instead of simply decompose because other decomposition methods could be added. What's the plan/intended usage pattern?

I have a situation where the decomposition could depend on the state that it is applied to. In particular, if you know that the gate is being applied to a computational basis state then there is a smarter decomposition than the default one. So I propose adding a method that takes a computational basis state as a parameter and outputs a decomposition that depends on it. Maybe we can call that one decompose?

Maybe I'm trying to be too general and I should just implement this method in my own gate?

[Strilanc]

I think default_decompose should stick pretty strictly to "here's how you get into (or closer to) 1 and 2 qubit gates with knowable matrices". This would be a separate thing.

You might want a different form of the gate, like ComputationalBasisBla?

It seems like the number of possibly-relevant details for decomposition is unlimited, and making a list of all of them in an args object is bound to be over-complicated.

[kevinsung]

Okay I made an issue to have a more specific discussion: quantumlib/OpenFermion-Cirq#252.