[arrays]: The OQ3 Spec mentions references but does not define what they are

[steleman]

What is the expected enhancement?

The OpenQASM3 Spec for Arrays states the following:

All array parameters are passed as references [ ... ]

The reference Type is not defined anywhere in the current Spec.

For clarity and completeness, we should define the reference Type, and its properties.

[jwoehr]

@steleman can you provide a model PR that would allow the spec to indicate more rigorously that array parameters are passed by reference as we all more or less understand the sense of things?

[steleman]

Arrays are a special and degenerate type of a fixed-size tensor. Unlike tensors,
arrays cannot be resized or reshaped.

The size of an array is constant and immutable, and is recorded once, at
declaration time.

Arrays allocate a contiguous block of memory of suitable size and alignment to
accommodate the storage of its elements.

If the array declaration is direct-initialized via initializer list, its elements
are initialized to the values provided by the initializer list.  Otherwise, the
memory allocated is not initialized, and is assumed to be garbage.

Partial initialization via initializer list is allowed - i.e. the initializer
list is incomplete, and does not provide values for all the elements of the array.
In this case, the elements that are not initialized via initializer list are not
initialized, and their values are assumed to be garbage.

As a special case, a direct initializer list declaration of the form:

  array[<type>, <size>] <identifier> = { <X> };

will initialize all the elements of the array to <X>, where <X> is of a type
suitable for initializing an element of the array, and if and only if the array
element type supports direct initialization from such a type.

It is unspecified whether the memory allocation of an array is of static storage
duration, or it is obtained via dynamic allocation. This property is implementation
dependent.

If the array memory is obtained via dynamic allocation, the implementation is
responsible for re-claiming the memory when the array object goes out of scope
(garbage collection).

Arrays may be passed as parameters or arguments to functions.

When passed as argument to a function, an array shall not cause a copy spill on
the stack. Several mechanisms are available to implement this constraint:

  - Use the C model: an array implicitly decays to a pointer to its first
    element, and only this pointer is passed as argument. For the array type
    case, a pointer is defined as the memory address of the first element of
    the array. This pointer may cause a copy spill on the stack. This does not
    imply that pointer types are generally normative to the language. This
    implicit conversion from array to pointer and back may remain opaque to the
    user.

  - Use the Fortran model: every array is described by an Array Descriptor.
    An Array Descriptor is an opaque type that contains descriptive metadata
    describing its corresponding array, including size and memory address
    boundaries. For function argument passing, only the Array Descriptor is
    actually passed to the function and copy-spilled on the stack.
    The implementation details of an Array Descriptor are unspecified and
    implementation dependent, however: size and memory address boundaries are
    normative.

An implementation is free to choose alternate mechanisms for passing arrays
as arguments to functions, within the constraints outlined above. The two
examples outlined above are not normative.

Arrays are statically typed, and cannot implicitly convert to or from any other type.

I think this also covers the constructor / destructor PR.

[jwoehr]

@steleman can you please comment on @blakejohnson 's question to #450 ?