Change operator precedence #4075
Conversation
josh11b
added
proposal
github-actions
bot
added
proposal rfc
| - It is used in an `impl` declaration to specify the values of associated | ||
| constants (such as associated types). In that context, `impl T as I where R` | ||
| is interpreted conceptually as `impl T as (I where R)`. It would be nice if | ||
| `T as I where R` would mean the same thing in other contexts. |
There was a problem hiding this comment.
Maybe worth noting here: if we don't get the "would be nice" version, we want it to be invalid rather than meaning (T as I) where R. That is, considered in isolation, we would prefer T as (I where R) > invalid > (T as I) where R.
| - The `where` operator will frequently be used with the binary `&` operator, | ||
| since that is how facet types are combined. It is desirable that | ||
| `I & J where R` be interpreted as `(I & J) where R`. This is expected to be | ||
| more common than combinging `where` and `as` outside of an `impl` |
There was a problem hiding this comment.
| more common than combinging `where` and `as` outside of an `impl` | |
| more common than combining `where` and `as` outside of an `impl` |
| `T as I where R` would mean the same thing in other contexts. | ||
| - The `where` operator will frequently be used with the binary `&` operator, | ||
| since that is how facet types are combined. It is desirable that | ||
| `I & J where R` be interpreted as `(I & J) where R`. This is expected to be |
There was a problem hiding this comment.
Likewise here: considered in isolation, we probably prefer (I & J) where R > invalid > I & (I where R).
There was a problem hiding this comment.
Just wanted to say I'm generally happy with this. Leaving the detail review to @zygoloid. I'm also not concerned if we discover we want to make a further tweak here based on experience, this still seems like a good improvement and bringing the where clause into the picture.
There was a problem hiding this comment.
Note to self: include link to open discussion on 06-13 https://docs.google.com/document/d/1s3mMCupmuSpWOFJGnvjoElcBIe2aoaysTIdyczvKX84/edit?resourcekey=0-G095Wc3sR6pW1hLJbGgE0g&tab=t.0#heading=h.p46elxrmhh8x
Update the operator precedence to achieve a few goals:
if...then...else, behave similarly to the left, so that rearranging expressions won't change how they group.whereoperator, used to specify constraints on facet types, to the precedence chart, to define how it interacts with other operators.