This PR is simple in what it does, but it deserves a very long explanation as to why suddenly I'm suggesting this. I'm not 100% convinced that we should go in this direction, although I now think it's harmless and it actually makes the language more powerful and easy to deal with (less noise).

First, what this PR does is that:

1. If there's a single yield expression and it's a tuple type, and there is more than one block argument, the tuple is automatically unpacked
2. If there is more than one yield expression, and the first one is a tuple type, and there is more arguments than the tuple size, the tuple is automatically unpacked

For example:

ary = [{1, 2}, {3, 4}]
ary.each do |tuple|
  # here `tuple` is a tuple, because there is one yield argument
  # and just one block argument
end

ary.each do |x, y|
  # `x` and `y` are unpacked, because there is one yield argument that is a tuple,
  # and there is more than one block argument
end

def foo
  yield({1, 2}, 3)
end

foo do |x|
  x # => {1, 2}
end

foo do |x, y|
  x # => {1, 2}
  y # => 3
end

# This is the second rule in action
foo do |x, y, z|
  x # => 1
  y # => 2
  z # => 3
end

If you are familiar with Ruby, you'll know that Ruby does rule 1 for arrays. Rule 2 is new in Crystal, and I think it makes more sense.

Note that this only works for Tuples, because their size if known at compile time. You can still use explicit unpacking for arrays if you want to (for tuples too, of course).

Now comes the long explanation as to why I'd like to include this in the language, and then why I think it's not "dangerous".

Since a few days, together with @jhass , we've been enhancing the language with a few missing things: splats in yields, splat in block arguments, and splats in generic types. One of the goals was being able to make Hash be an Enumerable. The idea was to make Enumerable be Enumerable(*T), so basically enumerable of more than one type (a tuple type), and Hash would include Enumerable(K, V).

Then we could implement each_with_index like this:

module Enumerable(*T)
  def each_with_index
    i = 0
    each do |*elem|
      yield *elem, i
      i += 1
    end
  end
end

That would work for Hash, because Hash does yield key, value, which will be bound to elem as a tuple, and then splatted back to the block.

The problem comes with select and others similar. This is the current implementation:

module Enumerable(*T)
  def select(&block : T ->)
    ary = [] of T
    each { |e| ary << e if yield e }
    ary
  end
end

This now is incorrect for Array, because we don't want this:

a = [1, 2, 3]
a.select { |x| x >= 2 } # returns an Array({Int32}), because T is {Int32}

However for Hash that works fine, because T is a tuple {K, V}.

The ugly solution is to check, in every Enumerable method, if T has just one element or many elements. This isn't only ugly, but also bad: if someone wants to add a new method to Enumerable she now has to do this check too.

So... how does it work in Ruby?

It turns out that Hash actually does yield [k, v]. That is, it doesn't do yield k, v, but yields an array instead. Here's the proof, it's C code. You can see that it checks the block arity: if it's more than 1 it avoids creating this small array and directly binds the values to the block arguments (this is an optimization).

So, because Hash yields an array, and arrays are automatically unpacked if they are the only argument yielded to a block, and the block has more than one argument, one can do:

hash = {1 => 'a'}
hash.each do |key, value| # here unpkacing happens
  key # => 1
  value # => 'a'
end

# One can also do:
hash.each do |kv|
  kv # => [1, 'a']
end

With that, when you do hash.group_by or any other Enumerable method, you can do hash.group_by { |k, v| } and auto-unpacking happens. It's very convenient.

However, when you do each_with_index, because more than one argument is yielded (the array and the index), auto-unpacking doesn't happen in Ruby:

hash = {1 => 'a'}

# Probably not what you'd expect
hash.each_with_index do |key, value, index|
  key # => [1, 'a']
  value # => 0
  index # => nil
end

But one can (has to) do:

hash = {1 => 'a'}

# Probably not what you'd expect
hash.each_with_index do |(key, value), index|
  key # => 1
  value # => 'a'
  index # => 0
end

That's why we couldn't translate this idiom well to Crystal, because our Hash does yield k, v, not yield({k, v}). And we don't have automatic tuple unpacking.

With automatic tuple unpacking the Enumerable problem is solved: we can do yield({k, v}) in Hash, and make Hash be Enumerable({K, V}) (which is what it really is, it's an enumerable of key-value pairs). I actually tried this and it worked flawlessly (all specs passed, and I even tried compiling other projects). We can use group_by, first, to_a and all other Enumerable methods, and because we have automatic unpacking we can write |key, value| instead of the more noisy and ugly |(key, value)|. We can then make NamedTuple an Enumerable too, very easily. This avoids a lot of boilerplate and redundant definitions.

There's still one issue: we'd need to use explicit unpacking in each_with_index. That's were rule 2 is nice: we don't need to use explicit unpacking. We can simply do:

hash = {1 => 'a'}

# each_with_index does `yield({key, value}, index)`, and because
# the first argument is a tuple type and we have more than one yield
# expression and more block arguments that the size of this tuple,
# auto-unpacking happens
hash.each_with_index do |key, value, index|
  key # => 1
  value # => 'a'
  index # => 0
end

I think this makes sense, as it's very common to want to iterate an object with more info, and the first object might be a tuple, so it makes sense to auto-unpack it even if there is more than one yield argument.

We could late consider unpacking not only the first argument, but other arguments, if they are tuples and there are enough block arguments. However, I'm not sure there is a strong use case to motivate this, and one can always use explicit unpacking for this.

For this to be "perfect", we should change reduce to yield elem, memo and not memo, elem. I think this is actually good, as it basically makes it more consistent: all enumerable methods yield the element first, and then extra arguments.

Now, automatic tuple unpacking might be considered "dangerous" (well, I actually don't know if this is true, I'm just guessing :-P). But I don't think it's dangerous: if I provide more block arguments, and I know that the first yielded value is a tuple, it's very likely that I want to unpack the tuple. Otherwise, why would I provide more arguments than the number of yielded expressions?

Note that one can still use explicit unpacking if one wants to. But I now think automatic unpacking is really, really powerful and convenient, and can probably have many use cases, and reduce a lot of noise. For example:

a = [1, 2, 3]
b = [4, 5, 6]
a.each.zip(b.each).cycle.first(10).each do |x, y| # no need to write |(x, y)| anymore
  puts "#{x} => #{y}"
end

Finally, this just comes now, and was pretty easy to implement, because implementing splatting in yields and block arguments prepared the ground for this (that was the hard part).

Thoughts?