The community has been building a Ruby 1.9 compatibility tip list on =20
my blog.  While most of the changes are good, a pattern is emerging:  =20=

Enumerable#zip was damaged in the translation.  The short story is:

* Making Enumerable#zip() return and Enumerable::Enumerator when =20
called without a block hid a very useful return value that was already =20=

in place.  Now we typically need `enum.zip(=85).to_a` to get the =20
expected results.
* Beyond being less attractive, Enumerable::Enumerator is quite a bit =20=

slower.  It looks like `enum.zip(=85).to_a` in 1.9 is about 12 times =20
slower than a straight `enum.zip(=85)` in Ruby 1.8.
* Making Enumerable#zip() stop at the length of the shortest =20
Enumerable among the receiver and arguments really hurt its =20
usefulness.  It now discards data and it's hard for us to prevent =20
that, since we need to lengthen all short Enumerable objects we plan =20
to use before the call.  The Ruby 1.8 system of limiting the result =20
set to the size of the receiver was much more powerful, in my =20
opinion.  We could find the longest or shortest Enumerable to get the =20=

length we wanted, filter out the `nil` containing groups it inserted, =20=

or trim the size of the Enumerable objects involved (easier than =20
expanding them).

So, I'm making a plea for restoring Enumerable#zip() to the cool =20
iterator we all know and love:

* Can we restore the Array return value?  We can still use =20
`enum_for(:zip, =85)` when needed.  This fits in with the other =20
iterators that have a useful return value like all?(), any?(), =20
count(), drop(), inject()/reduce(), none?(), one?(), sort(), and take().
* Can we revert to the 1.8 behavior of setting the result set length =20
to the length of the receiver and adding `nil` objects for shorter =20
Enumerable arguments?  That seems to give us a lot more control over =20
the end result.

Thanks for listening.

James Edward Gray II