Came up while reviewing Qiskit/Qiskit.jl#38 (adding Unitful.jl support for delays).
qk_circuit_delay() accepts a QkDelayUnit when writing, but there's no way to read it back. QkCircuitInstruction has name, qubits, clbits, params, but no unit field. If a circuit comes in from Python, the delay unit is just lost. Is there a workaround?
If not, is a unit field on QkCircuitInstruction (or a dedicated accessor) planned?
Related: the Python API defaults to unit='dt' for delays, but dt isn't in QkDelayUnit at all, so a Python circuit with a dt-unit delay can't round-trip through the C API. Is this intentional (e.g. because dt needs backend context to resolve)?
Both of these affect how we can expose delays in Julia bindings. Even just a note in the C API docs clarifying the current state and intent would help a lot.
Came up while reviewing Qiskit/Qiskit.jl#38 (adding Unitful.jl support for delays).
qk_circuit_delay()accepts aQkDelayUnitwhen writing, but there's no way to read it back.QkCircuitInstructionhas name, qubits, clbits, params, but no unit field. If a circuit comes in from Python, the delay unit is just lost. Is there a workaround?If not, is a unit field on
QkCircuitInstruction(or a dedicated accessor) planned?Related: the Python API defaults to
unit='dt'for delays, butdtisn't inQkDelayUnitat all, so a Python circuit with a dt-unit delay can't round-trip through the C API. Is this intentional (e.g. because dt needs backend context to resolve)?Both of these affect how we can expose delays in Julia bindings. Even just a note in the C API docs clarifying the current state and intent would help a lot.