-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Change operator precedence #4075
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
proposals/p4075.md
Outdated
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
proposals/p4075.md
Outdated
`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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise here: considered in isolation, we probably prefer (I & J) where R
> invalid > I & (I where R)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM and approving for leads.
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.where
operator, used to specify constraints on facet types, to the precedence chart, to define how it interacts with other operators.