-
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
Operator tokens #601
Operator tokens #601
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.
Generally looks good, but there are a few points I'm asking to clarify.
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.
I know there was a bunch of discussion in the #syntax Discord channel as well here, but a few orthogonal comments in the interim...
Also, to be clear, I quite like the high level direction. I think it is a nicely balanced set of trade-offs. Now we just need the details to be sorted out....
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.
At this point I think most of my concern is about whether we can make {
/}
handling match for binary operators without spaces, as noted on #syntax (a preference for commutative behavior where it's equally likely to get in the way of developers).
Allow unspaced binary operators to be followed by `{` or `[` for symmetry with allowing them to be preceded by `}` or `]` and in anticipation of struct literals that begin with `{`.
Looks good, thank you. 👍 |
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.
I don't think there are any remaining blocking issues here and I'm happy with the wording at this point. I've made a suggestion for potentially adding a bit more of the motivation, but I don't think that should block anything so approving. Submit away!
(I also resolved a couple of comment threads that seemed fully addressed. The only remaining threads are mine and as stated, I'm happy with @zygoloid resoling them and landing.) |
Co-authored-by: Chandler Carruth <[email protected]>
Proposal: lexical rules for operator tokens. Co-authored-by: Chandler Carruth <[email protected]>
The [Operators proposal #601](#601) got accepted and but the details were not updated in the design docs. Added `symbolic_tokens.md` file to add the details of the proposal and its discussion. Closes #1992 Co-authored-by: Avi Aaron <[email protected]>
Lexical rules for operator tokens.