-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Drop 'when _' support #6150
Drop 'when _' support #6150
Conversation
Ref crystal-lang#4837 I think this syntax has no use-case. It can be replaced with 'else' block always.
a5c9de7
to
6fdaf42
Compare
Note: this is currently invalid syntax: case foo
else
# bar
end But this was valid: case foo
when _
# bar
end I don't know the usecase of this, but it was spec-ed (in |
IMHO |
I think it was added for not generating invalid code from a macro generating case statements that would happen to only generate the else part. You use Probably we could support having only an else. I don't know why we chose this syntax. |
To be honest, I didn't know that existed. I'm pretty sure I added it at one point because it's fancy, but not very useful. Generating code in macros might be a reason to justify this, but we could just allow a single else instead, if we ever need this. |
Or maybe it was added when we added tuple support in case... Which is another thing I think is a bit useless, and can be replaced with an if else chain (the need for tuple case is not super common, so using if else now and then is fine). I think we should remove that feature too. |
It was added together with the tuple support and it make sense since _, b = expr
case tuple
when {0, _}
# ...
when {_, 0}
# ...
when {x, y}
# ...
end I think we should have some minimum amount of time to merge PR so others has time to jump in ;-) 12hs in weekend for a syntax change seems to little time. It is a corner case, I'm ok to the merge though. |
It's definitely useful for pattern matching. |
There's no such thing as pattern matching in Crystal. That's why _ was a bad idea, and why tuple in when was a bad idea. It makes it look like there's pattern matching, but there's not. So we should remove both. Case is just an if with === or is_a?, but that's not pattern matching. |
A bad point of foo = 1
case foo
when _
puts "when _"
when 1
puts "when 1"
end Which output is correct, Such a syntax introducing ambiguity makes us confusing and it will be called as bad parts in future. |
yes, please! |
Ref crystal-lang#4837 I think this syntax has no use-case. It can be replaced with 'else' block always.
Ref #4837
I think this syntax has no use-case. It can be replaced with
else
block always.