Provide default size to some variable types with unspecified size

[rmshaffer]

In some cases, expressions were assigned types without a size. One side effect of this is that OpenQASM subroutines can sometimes be generated with an unsized (i.e. machine-sized) return type, e.g. float rather than float[64].

For example,

@subroutine
def product(prog: Program) -> FloatVar:
    a = IntVar(2, "a")
    prog.declare(a)
    return a * 2.5

prog = Program()
z = FloatVar(0.0, "z")
prog.set(z, product(prog))

would produce an OpenQASM subroutine defined as

def product() -> float {
    int[32] a = 2;
    return a * 2.5;
}

where the return type is a machine-sized float rather than an explicitly-sized type (e.g. float[64]).

This change cleans up these cases (at least, the ones I was able to find) so that the variables have default sizes specified explicitly, which seems more consistent with the typical behavior of oqpy.

[jcjaskula-aws]

I think the problem is bigger than the type size. When one uses the overloaded return python keyword, the type hint is ignored leading to counter-intuitive behavior:

@oqpy.subroutine
def product(prog: oqpy.Program) -> oqpy.IntVar[64]:
    a = oqpy.IntVar(2, "a")
    prog.declare(a)
    return a * 2.5

prog = oqpy.Program()
z = oqpy.FloatVar(0.0, "z")
prog.set(z, product(prog))

produces actually:

OPENQASM 3.0;
def product() -> float {
    int[32] a = 2;
    return a * 2.5;
}
float[64] z = 0.0;
z = product();

Because of the limitation of the return keyword (cannot have multiple returns in a single subroutine), I wonder if we should discourage/deprecate it.

Concerning the default type size behavior, I would vote for making the machine-sized type default everywhere. Users could always force the size with the __class_getitem__ mechanism.

[anuragm]

@oqpy.subroutine
def product(prog: oqpy.Program) -> oqpy.IntVar[64]:
    a = oqpy.IntVar(2, "a")
    prog.declare(a)
    return a * 2.5

prog = oqpy.Program()
z = oqpy.FloatVar(0.0, "z")
prog.set(z, product(prog))

This happens because oqpy.IntVar[64] is not returning a new class, but rather a functool.partial function object. We should instead create a new class for each _SizedVar equivalent (using the type metaclass) and return that. https://docs.python.org/3/reference/datamodel.html#the-purpose-of-class-getitem

[jcjaskula-aws]

This happens because oqpy.IntVar[64] is not returning a new class, but rather a functool.partial function object. We should instead create a new class for each _SizedVar equivalent (using the type metaclass) and return that. https://docs.python.org/3/reference/datamodel.html#the-purpose-of-class-getitem

Still does not work with IntVar. In this particular case, it is really the return path that sets the OQ3 return type, not the Python type hint.

[rmshaffer]

Because of the limitation of the return keyword (cannot have multiple returns in a single subroutine), I wonder if we should discourage/deprecate it.

@jcjaskula-aws I'm a little confused by this comment - what would be the way to return values from a subroutine without using the return keyword?

[jcjaskula-aws]

You can use prog.returns (code here). This can be used at multiple locations within a subroutine.