Move zip and zip? to Enumerable and make it work with any number of Indexable or Iterable or Iterator

[asterite]

Because Enumerable only provides internal iteration (there's no next, unlike Iterator) and I think because at the time zip was written there was no Iterator at all, zip used to only work against Indexable things.

This PR changes that. First, zip is moved to Enumerable because the only requirement the receiver has is to be able to traverse its elements. However, the arguments can now be any of Indexable, Iterable or Iterator, and there can be any number of them.

Some examples:

a = [1, 2, 3]
b = "a".."c"
c = 9.downto(1)

a.zip(b) # => [{1, "a"}, {2, "b"}, {3, "c"}]

b.zip(a) # => [{"a", 1}, {"b", 2}, {"c", 3}]

a.zip(b, c) # => [{1, "a", 9}, {2, "b", 8}, {3, "c", 7}]

# Don't do this at home :-P
(1..5).zip(Dir.open(".")) #=> [{1, "."}, {2, ".."}, {3, "man"}, {4, "CODE_OF_CONDUCT.md"}, {5, "compiler_spec"}] 

All of the above also work with the block version.

It's nice to see that the above snippet also works exactly the same as in Ruby :-)

It might be a bit strange that the receiver has to be Enumerable but the arguments have to be of different types, but the truth is that, at least in the std many/most of the type implement Enumerable, Iterable and Iterator at the same time.

Is this useful? I'm pretty sure it has its usecases (zipping two or three sequences at the same time). It can also be good for "competition" problems. But ultimately, this is a more complete and powerful version of the existing zip, and the implementation isn't that complex.

Bonus snippet: another way to do each_with_index:

['a', 'b', 'c'].zip(1..) do |e, i|
  puts "#{i}) #{e}"
end

(but it's probably a bit slower than each_with_index)

[asterite]

@r00ster91 Thanks! I found it easier to apply the suggestions locally and then force push everything. Let me know if it's good now.

[straight-shoota]

Sounds good! 👍

[yxhuvud]

How does that type resolution handle a other collection whose elements are nilable?

[asterite]

It's the tuple that becomes nilable because the compiler can't know whether the block will be called (or something like that). This doesn't affect individual elements.

[bcardiff]

I’m late to the review. But I wanted to say that i liked the flexibility this PR brings. And also the tricks of using typeof of the yielding methods to be able to type the resulting array.

[asterite]

@bcardiff Oops, sorry I didn't wait for your review. I remembered you said it was approved but I forgot you wanted to review it.

Yeah, typeof keeps rocking it :-)