Jake Lishman

Choosing the "minimal depth" means the number isn't suitable for any of the places we actually use it - it would allow termination of the optimisation loops without considering the...

Updated with comments from the dynamic-circuits meeting on Monday, and ready for final review.

Updated with Kevin's comments and ready for review again. For top-level visibility: offline, we decided to remove the changes to `QuantumCircuit` from this iteration, including not making the `QuantumCircuit` properties...

Ready again, hopefully for the last time!

A slight alternative of course is to speed up the `Operator` constructor path. There's no real reason that we should be calling `QuantumCircuit.to_instruction` to handle circuits (which I'm pretty sure...

From the meeting: we might want to replace this with the utility decorator on top of the `run` method to do the trivial recursion.

I thought I'd added this further comment here already, sorry: I think this is one pass we'll want to do a little bit of a refactor before doing the recursion...

As discussed, I've updated this PR to only recurse the post-setup "run" loop component of the pass, and to use the new utility functions added in #8752.

For reference, [this is Chris's answer on stackexchange](https://quantumcomputing.stackexchange.com/a/8371/18472). The relevant docstrings that need updating are the `QuantumCircuit.barrier` method and the `Barrier` class.

There's a limit on how much we can do for `QuantumCircuit`, because we can't _really_ output something that can `eval` back to the input, but we could definitely do better...