Add complex assignments (e.g. +=) #2241
Conversation
| <td>|e1| = |e1| << |e2| | ||
| </table> | ||
|
|
||
| Note: in all of the cases above, |e1| is guaranteed by a combination of the syntax and typing rules to be composed of some optional sequence of `*` and `&` followed by an identifier. |
There was a problem hiding this comment.
I dislike that the constraints on the LHS are unlike for regular assignment.
Instead, I would rather that the LHS is a reference that could be on a regular assignment, and whose store type allows the operation.
And then the translation for
LHS op= RHS
would be
{ let p = &LHS;
*p = *p op RHS }
Then there is no concern for issuing side effects multiple times.
There was a problem hiding this comment.
Hm.. Except for the component-of-a-vector case.
var v = vec4<f32>();
v.y += 1.0;
We can't take the address of a component of a vector. :-(
There was a problem hiding this comment.
The only difference in syntactic constraints with regular assignment is that _ is not allowed on the LHS side.
The meaningful constraints are in terms of type, and they flow naturally from the fact that the expression on the LHS must also be a valid left-operand to the operator.
My hope was that by making complex assignments mere syntactic sugar I could both minimize implementers' burden, and make it conceptually easy for programmers.
There was a problem hiding this comment.
The only difference in syntactic constraints with regular assignment is that _ is not allowed on the LHS side.
Maybe I was confused.
This PR has the LHS as unary_expression. That might work, but I'd see it more clearly as similar to regular assignment if it uses lhs_expression. I kind of got lost tracing back through unary_expression to see what it expands to.
|
After discussing it with Myles, I realized that my proposal could lead to duplicated work in the following case: Since David correctly noted that taking the address of the LHS fails for vector component, this leaves no easy solution (we would need to do something different depending on the type of the LHS), and I no longer think that this is appropriate for V1. So I am cancelling the PR. |
|
Isn't a simple fix to disallow the compound operators on vector elements in v1? |
|
I'm not sure that I understand why this is hard to spec. I don't think we need to try and come up with an equivalent WGSL translation, we just need to say something like:
This is how compound assignment is described in the C/C++ standards as well. This seems very low cost to spec, test, and implement, and has clear benefits for shader authors who would expect this work (HLSL, GLSL, and MSL all have this). |
|
Interacts with #2261 |
WGSL meeting minutes 2021-11-09
|
|
Also unclear to me what went wrong here. Previously, when we discussed |
You're right. I think James pointed that out in the meeting. That you can have a reference to a component of a vector, which is why Like @jrprice said above: This feature can and should be rescued by stating the semantics directly, not as a translation to some other WGSL that uses pointers. I have time today so I can reframe this PR in that way. |
Can it be described in terms of references? |
Yes. But the reference has to be evaluated only once. So it's not a pure syntactic sugar replacement. PTAL #2345 |
|
Closing since this has been done in #2345 |
Inspired by #2204.
It has not been discussed by the group yet, and thus should not be merged.