Move MResetZ to Intrinsic namespace?

[tcNickolas]

Now that Q# requires resetting qubits to |0> before releasing them, not just measuring them, I find myself using MResetZ a lot more often than with the classic QDK, and every time I need to open Microsoft.Quantum.Measurement namespace. (There's also no Quick Fix to automate this.)
Moving it to Intrinsic seems logical, since it's so frequently used in the code.

[swernli]

I agree that needing to constantly manually or via completion include open Microsoft.Quantum.Measurement; at the top of the file is annoying and have also thought about whether more measurement intrinsic operations should be automatically available. That said, moving an operation from one namespace to another can cause problems for existing programs, and duplicating the operation across multiple namespaces is also tricky and confusing until deprecation warnings are supported. As an alternative that seems less disruptive, we could add Microsoft.Quantum.Measurment to the prelude:

qsharp/compiler/qsc_frontend/src/resolve.rs

Lines 25 to 29 in 9f90eaa

	const PRELUDE: &[&str] = &[
	"Microsoft.Quantum.Canon",
	"Microsoft.Quantum.Core",
	"Microsoft.Quantum.Intrinsic",
	];

That would allow users to call operations from the namespace without an explicit open in the same way they can for M, Measure, and other gate operations. The prelude is always superseded by explicitly opened namespaces or locally defined callables, so it won't change any existing code, just make future code easier, and allow any samples to be updated to remove the explicit open of the measurement namespace. The callables in the measurement namespace are:

operation MeasureAllZ (register : Qubit[]) : Result { ... }
operation MeasureEachZ (register : Qubit[]) : Result[] { ... }
operation MResetEachZ (register : Qubit[]) : Result[] { ... }
operation MResetX (target : Qubit) : Result { ... }
operation MResetY (target : Qubit) : Result { ... }
operation MResetZ (target : Qubit) : Result { ... }
operation MeasureInteger(target : Qubit[]) : Int { ... }

Of these, only the last one feels a little odd to be available automatically, but even there the operation is self-contained (the implementation doesn't depend on any other utility functions as it calculates the integer directly itself rather than using any conversion functions like ResultArrayAsInt) and it is already specific to the "unrestricted" configuration. Given that, it seems like this would be a safe namespace to include in the prelude and make authoring Q# code that uses the measure-and-reset operations easier.

If no one is opposed, that would make this a one line change to the PRELUDE variable mentioned above.

[tcNickolas]

I'm not sure moving callables to a namespace that is already in Prelude is a breaking change, since everything from those namespaces is already open by default. (Also, I didn't realize Canon was in the prelude too... Need to go back and update some code :-) )

This approach sounds fine to me. Though now I'm wondering why we have multiple separate namespaces to store callables that are available without opening a namespace...

[swernli]

I'm not sure moving callables to a namespace that is already in Prelude is a breaking change, since everything from those namespaces is already open by default. (Also, I didn't realize Canon was in the prelude too... Need to go back and update some code :-) )

It's a narrow corner case, but if anyone was using the fully qualified name, Microsoft.Quantum.Measurement.MResetZ for example, then it would break their code. This is not very likely/common, but the one place where it does come up is when differentiating between two APIs with the same name that are both in scope.

This approach sounds fine to me. Though now I'm wondering why we have multiple separate namespaces to store callables that are available without opening a namespace...

This is definitely a good thought for our eventual module-based future (@sezna FYI). What does the prelude become and how do we reason about it when we have modules? Should everything in the prelude be in the same module or should multiple modules be in the prelude? Food for thought...

Sound like the one-line change will work for now thought!

[sezna]

Dumped some initial thoughts here re: prelude, as it is out of scope for this issue: #1203