This should be possible with a small change. Let me take a stab at it.

If we are doing this, we might as well allow full aliasing such as:

from cudaq import kernel as k, qubit as qb

@k
def f():
    q = qb()

f()

This should be possible with a small change. Let me take a stab at it.

I'm don't think it will be a small change. The strings cudaq, numpy, np, qubit and friends are hardcoded in the bridge. In the end this is a symptom in of a deeper issue. Given your example, which I agree it should be supported:

from cudaq import kernel as k, qubit as qb

@k
def f():
    q = qb()

f()

cuda.qubit is not a object the bridge can reason about. Even before that, the bridge won't even try to resolve cudaq.qubit to an object, this is effectively a keyword in the current CUDA-Q. In this case, the bridge sees qb() and it does't know what to do about it. It is likely to be seen as a call to an unknown function.

The correct thing to do here would be something along these lines: resolve qb, seeing that qb = cuda.qubit, then the bridge gets the cudaq.qubit object and in it there should be a way to tell the bridge what to do on a call such as cudaq.qubit().

I got the import cudaq as quda change done with relatively small changes (only tested some simple examples). the qubit as qb is indeed proving to be challenging.