-
-
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
[Minor breaking] Allow named arguments in commands and streamline type expressions #19383
Conversation
PR is pretty much done with some minor things listed above. Leaving it as draft until it's safe to merge breaking changes like this. |
It's hard to foresee the effects this has on existing code. I do like the changes though. But it's time to derive the parser from a formal grammar, we want to encourage alternative implementations and better editor plugins. |
What's the difference with normal PEG? Indents? |
Yes. |
Decided to unmark as draft considering how rarely breaking this is. Any choice is fine with me. |
6395a7c
to
d5dc3fb
Compare
Types are separated from expressions and better reflected in the grammar.
d5dc3fb
to
b51f21c
Compare
When will this be reviewed? |
Bump, this would be really nice to have before new parser PRs |
moved to #20994 |
Closes nim-lang/RFCs#442, closes #15050, closes #8846 and maybe some other issues, cleans up after #19181, closes #19313.
Types are separated from normal expressions in the grammar.
object
,tuple
etc are special in type sections and cannot directly be used as expressions. This gives errors similar to #19313 for objects and tuples (which is reflected by the ordered choice in the grammar) and is fixed by wrapping in parentheses.ref
andptr
(and alsodistinct
because a package was usingdistinct object
) are also special, but this is only whenobject
andtuple
immediately follow.foo a = b
previously meantfoo(a) = b
, now it meansfoo(a = b)
. This only applies to statement form expressions,exprStmt
in the grammar, although this is not reflected in the grammar yet as it would be pretty complicated. Currently it uses a PrimaryMode enum field instead. Allowing this also resulted in line info of commands being more accurate, and commands now terminate on dedented commas which was not the case before.Both of these are (minorly) breaking. Changing code to make these work is very easy, however the second one will not give a direct syntax error upon being wrong and the first one gives errors that were not previously given. For this reason it can be delayed. #19191 and #19181 also had parser changes, but these added new syntax and were non-breaking.