Clarify semantics of input and output

[jlapeyre]

The documented semantics of input and output is quite permissive. Here are a few questions.

Are the following allowed, and if so, what do they mean?

1. input int[32] x = 1;
2. input int[32] x;, and assigning to x at a later point.
3. const input int[32] x;
4. const output bit[32] x;
5. input in non-global scopes
6. output in non-global scopes
7. output on identifiers of type other than bit.
8. input qubit q, and output qubit q

Some thoughts

1. I think this should be illegal. Or you could let x take its input value either before or after the initializer assignment. In one case the input value is ignored, in the other, the initializer value is ignored.
2. Between the declaration and the assignment to x it has its input value. But I would make this illegal.
3. const means a) the variable cannot appear as an lvalue. and b) that the value can be computed at compile time. Here b is not satisfied. So this should be illegal. Or you could give this construction different semantics, namely accept that the value can not be computed at compile time. This would add some complexity. In particular, implementers would have to track the two different meanings of const.
4. Just like 3. This could be useful as it prevents x from being clobbered. But const has different semantics than the documented one.
5. In a def routine, this might mean that the the variable is reinitialized to the run time input value every time control flow reaches the input statement.

And

7. Would allow users to do postprocessing of outcomes and retrieve only the results of some reduction. In practice, users would invent lots of uses that would have to be supported in general.

8. is certainly not intended to be allowed. But this should be explicit in the spec. That is: "... one or more classical variable declarations".

I think it would make life easier for programmers and implementers if neither input nor output variables can be lvalues.

[jlapeyre]

This was discussed in today's TSC meeting. The result is that a PR with the following has a good chance of being merged:

• 1, 3, 4, 5, 6, 8 should be disallowed
• 7 should be allowed

Number 2 requires more thought and will be reviewed in the TSC meeting of 10 January 2024.