Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency in default classical register names #12192

Open
wshanks opened this issue Apr 16, 2024 · 1 comment
Open

Inconsistency in default classical register names #12192

wshanks opened this issue Apr 16, 2024 · 1 comment
Milestone

Comments

@wshanks
Copy link
Contributor

wshanks commented Apr 16, 2024

With the SamplerV2 using the names of classical registers as part of structure for storing results, classical register names have become more important than they were in the past with qiskit.result.Result which just put all the registers together. So

circ = QuantumCircuit(1, 1)
circ.measure(0, 0)

stores a result in classical register c while

circ = QuantumCircuit(1)
circ.measure_all()

stores a result in classical register meas and

circ = QuantumCircuit(1)
circ.measure_active()

stores a result in classical register measure.

I think ideally all three patterns would store into the same classical register name by default.

Given that the current behavior has existed for a while, I think it might be too hard to change it now, but I wanted to capture it at least. The defaults could be migrated to a common name, but in the transition period users would need to be more explicit about register names (since I think the way to do it is keep the old default but issue a warning that the default will change, so users would need to start passing the new default explicitly to prepare for it) and once everyone is being explicit it might not be worth trying to let people be more lazy by using the new common default name.

@wshanks wshanks changed the title Inconsistency in classical register names Inconsistency in default classical register names Apr 16, 2024
@1ucian0
Copy link
Member

1ucian0 commented Jun 12, 2024

As per discussion in #12345 (comment) , I think changing the default names should be consider a breaking change and, therefore, for the next major release (2.0). Adding it into the 2.0 milestone.

@1ucian0 1ucian0 added this to the 2.0.0 milestone Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants