[WIP] [lang] Qubit mobility

[boschmitt]

Problem

The current implementation of CUDAQ C++ extensions poses a significant challenge. It has stringent constraints on the qubit type, disallowing the copy and move of qubit objects. This limitation hampers our ability to advance the CUDAQ towards a higher level of abstraction.

Background

In CUDAQ, quantum computations happen inside kernels that modify the state of a quantum abstract machine by applying quantum operators on qubits. (Note: The quantum abstract machine may be implemented classically (using a simulator) or on quantum hardware.) Qubits are instances of the class cudaq::qubit, a class carefully designed to prevent the manipulation of qubits in non-physical ways.

Out of the many quirks in quantum mechanics, two played a significant role in the conception of the cudaq::qubit type:

1. The no-cloning theorem excludes the possibility of copying an arbitrary (unknown) quantum state.
2. Entanglement: it is not always possible to describe the state of a multi-qubit quantum system as the combination (tensor product) of one-qubit states, e.g., the Bell states. We say that such states are non-separable.

To adhere to (1), we decided that instances of cudaq::qubit cannot be copied or moved. Dealing with (2) forced us to introduce a level of indirection for representing the state of the quantum abstract machine. Indeed, the existence of non-separable quantum states compelled us to implement the qubit class as a type that does not carry a quantum state. Instead, an instance of this type is an interface to a "portion" of the underlying quantum state. (Effectively, something akin to a pointer.)

Note that our solution for adhering to (2) also makes the cudaq::qubit type compliant with (1). Since qubits are just interfaces through which we modify the quantum state, their copy or move does not necessarily imply the copy or move of the underlying quantum state. Thus, language-wise, there is no quantum-mechanical impediment to allowing these operations. For example:

cudaq::qubit q0;
cudaq::qubit q1 = q0;
// The above means that both `q0` and `q1` are interfaces
// to the same underlying portion of the quantum state.

cudaq::qubit q0;
cudaq::qubit q1 = std::move(q0);
// The above means that `q1` will be an interface to the quantum state portion
// originally interfaced by `q0`, and `q0` will become an "invalid".

Details

It is a fairly common pattern to have objects in a program to represent something outside themselves, i.e., they are not "data" but some resource identity. CUDAQ implements the cudaq::qubit type in this way; it is an RAII-style resource manager. It manages quantum memory: upon construction, it acquires access to a portion of the system's underlying quantum state and initializes it to some state. Its destruction releases this access. This design is typical in C++ and facilitates memory handling: users do not need to worry about freeing quantum memory.

Currently, this acquired access is unique and non-transferable. Indeed, we disallow both the copy and the move operations on qubit objects. This design complicates some aspects of CUDA Quantum:

1. It complicates using qubits with standard containers. (Thus, we have cudaq::qvector.)
2. It prevent us from even considering adding high-level quantum types and expression. For example, imagine a quantum integer type, cudaq::qint, build on top of cudaq::qubit that could be used to compose expression such as: cudaq::qint result = a + b + c, where a, b, and c are also quantum integers.