Fix yielding block return type restriction underscore#10929
Fix yielding block return type restriction underscore#10929straight-shoota wants to merge 1 commit intocrystal-lang:masterfrom
Conversation
There's an unintended subtle difference for yielding blocks and underscore return value. See crystal-lang#10467 (comment)
|
I think this is wrong. Underscore means anything can be returned. Omission of a type means Nil. Maybe omission should mean anything, but too late. |
|
I'm surprised this isn't failing. Can I fix the underlying issue instead? Block restrictions work a bit different if a block is captured or not. |
|
Of course to fix this I first need to understand the problem. Could you describe what this is solving? |
|
Okay, I think I understand now. A bug should have been reported instead of just a mention in the forums. I can try fixing underscore for the NoReturn case. |
|
Here we go: #10933 I think the fix should be pretty safe. It's doing less work than before if the return type is an underscore. There's probably no way this introduced a regression. |
|
Yes, this might be wrong as it's not the syntax we would ideally want to use. But it makes sure things work with the current compiler semantics. def foo(& : ->)
yield
end
foo { 1 } # => 1Maybe it should. We can discuss that in #10931. |
|
With #10933 being merged these changes are not necessary and mostly unintended when the output values of the block parameter are being used (see #10931 (comment)). I'll create a new PR for any intended changes. |
There's an unintended subtle difference for yielding blocks and underscore return value.
See #10467 (comment)
This patch replaces all underscore return types in yielding block parameters to avoid potential issues with that. This is essentially a workaround for wanky compiler behaviour.
Related to #10928