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

Designing and implementing iterators that work well when the underlying 
collection is changed isn't trivial at all. For some (somewhat old) 
background, I suggest reading
http://www.scharf.gr/eclipse/blog/robust_iterators/Robust%20Iterators%20in%20ET.pdf

Regards,   Martin.

On 2015/09/01 01:08, Daniel Doubrovkine wrote:
> (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.
>