Parser: allow anonymous block args #8117
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #7157
In addition to being able to write this:
Now you can write it like this:
That is, you can omit the block name.
Of course it also works with a type signature:
It might look more obscure but there's a reason we might go this way.
Why?
Right now the compiler infers a few things based on the signature and method definition:
yield
inside it the compiler knows it receives a blockThis is nice but it has a few disadvantages:
yield
and omit the block argument it's not immediately clear from the method signature whether a method accepts a block or not&block
if you want to say you receive a block, even if you don't plan to yield (Nil#try
does this) so it's a bit asymmetric that sometimes you need to write it and sometimes notyield
is generated through a macro then you are again forced to specify the block argumentSo the idea would be:
&
means a non-captured block argument: because it doesn't have a name there's no way to capture it&block
means a captured block argument, and the compiler will verify that it's used in the semantic phase (because it might be mentioned inside a macro)&block
without a mention will give a compile error suggesting to either change it to&
to avoid a closure or to mention it somehowyield
and the method signature doesn't have&
the compiler will tell youNow, this PR is just the beginning direction: there's no breaking change here, just the possibility to omit the block argument name.