Open Discussion: Transpiler Passes and PassManager

[Shobhit21287]

Qiskit’s transpiler passes are now exposed through the C API, but many of those passes are still missing from the C++ bindings. The C++ bindings also don’t include a PassManager (which exists in python and since it isn't a bottleneck, it wont be ported to rust anytime soon) Here are a few open questions to discuss.

• Is there a plan to expose additional transpiler passes in the C++ bindings?
• What’s the preferred approach for adding them through the bindings?
• Is it a good idea to explore the idea of a PassManager that is native to the C++ bindings or maybe something that exists within the C-API?
• What could be the possible ways that qiskit-cpp can be integrated by other communities in their workflows and does that possibly add functionalities native to qiskit-cpp?

[aaryav-3]

Before deciding whether the PassManager should be ported to Rust and exposed via the C API, it may be worth reassessing what concrete benefits it provides at the present moment, and whether those benefits translate well outside Python (based on a discussion with @jakelishman).
A few points to consider:

• Runtime conditional logic is supported by the PassManager, but this is rarely used in practice (only one existing pass relies on pre-run checks). Similar behavior can already be implemented directly by users via property_set, which is native to BasePass.
• Parallel execution in the PassManager leverages Python’s native multithreading. Replicating equivalent behavior in lower-level languages would require significantly more complexity around memory management and scheduling.
• The PassManager is designed to be pluggable with preset_passmanagers, allowing users to inject custom passes into arbitrary stages. However, any custom pass must still conform to the same input/output types (QuantumCircuit / DAGCircuit), which may limit the practical value of this flexibility.

Given that many standalone transpiler passes are now available through the C API, but are not yet exposed in the C++ bindings and that the C++ bindings currently do not include a PassManager, the following questions seem open:

• Should additional transpiler passes be exposed in the C++ bindings (and possibly the DAG circuit class, to help with IR-handling and pass interoperability) before we can assess whether managing these intermediate layers via a PassManager is a tractable change?
• Should we explore a PassManager that is native to the C++ bindings, or one that potentially lives within the C API and Rust code?

Thanks!