[ruby-core:70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields

(this is my first time e-mailing list list, so apologies for any misstep :)

I wanted to bring up the behavior of an iterator if it is modified inside
of the block to which it yields. I ran into this in
https://github.com/rubinius/rubinius/issues/3494 and it has already been
discussed in https://github.com/rubinius/rubinius/issues/547 (and I am sure
elsewhere). These issues repeatedly get closed with "mutating a collection
while iterating over it is unsupported".

And this has been brought up on this list, see
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/23633 to which
Matz replied:

It is undefined behavior of iterators if the block modifies iterating
object. It may crash or fall in to infinite loop.

This all seems to make sense, however right now at least two Ruby
implementations have predictably different behaviors (MRI vs. Rubinius) and
there're clearly some gems (eg. https://github.com/joeyAghion/spidey) that
rely on this (likely incorrectly). But that itself doesn't mean much, it's
just for context.

I'd like to suggest we change the behavior from "undefined" to "defined" in
some future version of Ruby. It seems that in the real world such behavior
is very well defined, ie. if you're climbing an escalator and a step
appears in front of you before you jump off, you're going to be stepping on
it and not having "undefined" behavior :)

Any thoughts?

Thanks!
-dB.

-- 

dB. | Moscow - Geneva - Seattle - New York
code.dblock.org - @dblockdotorg <http://twitter.com/#!/dblockdotorg> -
artsy.net - github/dblock <https://github.com/dblock>