-
Notifications
You must be signed in to change notification settings - Fork 90
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
Allow metadata keywords in field position #1768
Conversation
Metadata keywords (optional, default, etc.) are numerous and they can't clash with field names, because they don't appear in the same positions. Thus, to avoid having user to quote their fields, this commit allows unambiguously the usage of metadata keyword in field position.
@@ -1,141 +1,165 @@ | |||
# test.type = 'pass' |
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.
This file has a big diff because I formatted it with Topiary. You can ignore most of the changes but the very end, where I added a test for metadata keyword in field position.
@@ -557,6 +557,30 @@ Match: Match = { | |||
// A default annotation in a pattern. | |||
DefaultAnnot: RichTerm = "?" <t: Term> => t; | |||
|
|||
// A metadata keyword returned as an indent. In some positions, those are |
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.
Can we do this for all (or most) of our keywords? I think even a let
or rec
should be unambiguous in field name positions.
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 would vote for doing this for metadata keyword only at first. Although I don't have right now any example of an existing keyword or a future extension that could cause an issue, let's just give it a bit more thinking (metadata keywords are much more restricted in where they can appear). At worst we can do that in a follow-up PR.
Closes #1765.
Metadata keywords (optional, default, etc.) are numerous and they can't clash with field names, because they don't appear in the same positions. Thus, to avoid having user to quote their fields, this PR allows unambiguously the usage of metadata keyword in field position.
I suspect we could actually proceed with even more keywords of the language, but let's start small and avoid shooting ourselves in the foot. The metadata keywords is the set which isn't small and is likely to grow, while the other keywords should stay relatively stable.
Note that currently metadata keyword are rejected within let destucturing, because destructuring binds variables, and variables which are keywords can't be accessed in the current syntax. We might change that if we ever implement raw identifiers.