Hi Joseph, On 11/12/22 15:54, Joseph Myers wrote:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:Since it's to be used as an rvalue, not as a lvalue, I guess a postfix-expression wouldn't be the right one.Several forms of postfix-expression are only rvalues.(with a special rule about how the identifier is interpreted, different from the normal scope rules)? If so, then ".a = 1" could either match assignment-expression directly (assigning to the postfix-expression ".a").No, assigning to a function parameter from within another parameter declaration wouldn't make sense. They should be readonly. Side effects should be forbidden, I think.Such assignments are already allowed. In a function definition, the side effects (including in size expressions for array parameters adjusted to pointers) take place before entry to the function body.
Then, I'm guessing that rules need to change in a way that .initializer cannot appear as the left operand of an assignment-expression.
That is, for the following current definition of the assignment-expression (as of N3054):
assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression
The unary-expression cannot be formed by a .initializer.
Would that be doable and sufficient?
Cheers,
Alex
And, in any case, if you did have a constraint disallowing such assignments, it wouldn't suffice for syntactic disambiguation (see the previous point I made about that; I have some rough notes towards a WG14 paper on syntactic disambiguation, but haven't converted them into a coherent paper).
-- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
