Develop a consistent strategy on "automatically resetting or not resetting all qubits on release".

[kuzminrobin]

Discussion.

Copy: cgranade This appears to automatically reset all qubits on release, but that's not the semantics used in any other of our simulators, I believe. I know @swernli led a discussion on that about a year ago, may be good to get his take here.

swernli I appreciate the callout! This is indeed an area fraught with options, and one we've gone back and forth on. We fixed the fullstate simulator's QIR execution to treat releasing non-zero qubits as errors, making it consistent with how local simulation via C# works, only to get the feedback that this behavior interferes with running QIR programs from non-Q# languages where this convention is not enforced. Given that feedback, I think there was desire to remove the error even for the fullstate simulator, at least when running QIR, but I believe it's still something of an open question.

Given all of that, I think the behavior written here makes sense, even though it can cause side effects. Changing it to be an error is something we should leave until we have a more definitive decision regarding the behavior of our other simulators.

cgranade Sounds good. Whatever way we decide to go on that, we should probably be consistent and make sure that's well documented. I think there's likely still a lot of parts of the Q# docs, for instance, that assume that implicit resets don't happen after releasing qubits, such that optimizations from coherent unpreparation are allowed — if we decide for always implicitly resetting, those docs and samples will likely need to be updated.

[swernli]

For additional context, see previous issues on this topic for QIR (https://github.com/microsoft/qsharp-runtime/issues/552) and C# infrastructure (https://github.com/microsoft/qsharp-runtime/issues/206). As mentioned above, we may be phasing out this behavior for QIR, but there are still open questions. @bettinaheim FYI.