The following two aspects of the "Comma" may be implicit in it being listed in the documentation within the list of expression operators
Maybe #2. Definitely not #1. Merely being an operator implies nothing about what its result will be.
1/ the fact that the value (result) of a comma expression is the result of its leftmost expression.
It should perhaps also be explicitly stated that this behaviour is specific to v1.
even though it's (I assume) parsed as a := (1, (b := (2, (c := (3, (d := 4))))))
Note:
Expression Operators (in descending precedence order)
...
:= Assign
...
, Comma (multi-statement)
Assignment has higher precedence, therefore the grouping is
(a := 1), (b := 2), etc.
Also,
For example: x:=1, y+=2, ++index, MyFunc(). Such statements are executed in order from left to right.
With the grouping you show, the assignments would be evaluated right to left.
This also aligns with function calls, where evaluating
Fn(a := 1, b := 2) as
Fn(a := (1, b := 2)) wouldn't make sense.
Do you still think that it is "intuitively clear"?
the fact that a comma expression is a single expression ... should be described in the documentation as "Comma (multi-expression)"
Do you see the irony?
I think the sub-expressions of
x:=1, y+=2, ++index, MyFunc() might be referred to as
statements rather than
expressions because:
- Any value that they might produce is not being used.
- They are executed for their side-effects, not evaluated for their overall value.
- They could be used alone on a line, as a statement.
(That isn't true for all sub-expressions that multi-statement comma accepts, but is true for most that make sense to use.)
The current name is well established, and I think there isn't a better, more accurate one.
I think raising user awareness of when they can
omit braces is not a priority.