-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify semantics of input
and output
#493
Labels
enhance/change spec
Semantic changes to language, not clarification
Comments
This was discussed in today's TSC meeting. The result is that a PR with the following has a good chance of being merged:
Number 2 requires more thought and will be reviewed in the TSC meeting of 10 January 2024. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The documented semantics of
input
andoutput
is quite permissive. Here are a few questions.Are the following allowed, and if so, what do they mean?
input int[32] x = 1;
input int[32] x;
, and assigning tox
at a later point.const input int[32] x;
const output bit[32] x;
input
in non-global scopesoutput
in non-global scopesoutput
on identifiers of type other thanbit
.input qubit q
, andoutput qubit q
Some thoughts
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.x
it has its input value. But I would make this illegal.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 ofconst
.x
from being clobbered. Butconst
has different semantics than the documented one.def
routine, this might mean that the the variable is reinitialized to the run time input value every time control flow reaches theinput
statement.And
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.
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
noroutput
variables can be lvalues.The text was updated successfully, but these errors were encountered: