Implement auto-tuple unpacking in block arguments, Rule 1 #2783
Conversation
asterite
force-pushed
the
feature/block_auto_unpack_rule_1
branch
2 times, most recently
from
5b1cc4c to
063277b
Compare
|
@ysbaddaden What's your opinion on this? |
😍
Better consistency here!
I want to keep it, too. I'd hate For this same reason, Rule 2 would be nice to have. I don't think it would do any harm, especially with the compile-time checks you propose. If there are exactly as many args as yielded values => no unpacking, if there are more args than yielded values => try to unpack, if there are too many args available than values to unpack => compile error (broken expectation) ; if there are too few args available than values to unpack => compile error (can't fit). |
asterite
force-pushed
the
feature/block_auto_unpack_rule_1
branch
from
063277b to
ca12dce
Compare
|
Let's start with rule 1 and later see if rule 2 turns out to be convenient or not. |
This is similar to #2778 but only Rule 1 (explained there) is implemented.
Additionally, an error is now given if more than expected block arguments are passed, as explained here.
Finally, the code has version checks so that in 0.18.0
Hashwill beEnumerable, as well as a few other types (HTTP::Headers,HTTP::ParamsandENV). These checks will disappear once we make a new release, but it allows us to avoid having to do an intermediate release that can use the new behaviour.I personally still like Rule 2 and see no harm in it, specially if combined with the error when extra block arguments are passed. Could be nice for
each_with_indexandeach_with_object, when used on aHash. But since there aren't many cases of that in the compiler (about ~6) and just a few in other projects I tried, maybe it's not very important.I'd still like to be able to do
hash.each { |key, value| ... }instead ofhash.each { |(key, value)| ... }, mostly because the later doesn't add any type safety, just noise. Basically, if I specify more arguments is because I'm expecting a tuple unpack to happen. If that's not the case (it's not a tuple), I get a compile error, so mistakes can't happen. With Rule 2 it's a bit more complicated because there are many more variants to consider.