I'd like to propose a new method for Enumerator which returns whether there will be a next value in the enumerator when calling
It should work like this ruby demo:
class Enumerator def next? peek true rescue StopIteration false end end a = [1,2,3] e = a.to_enum p e.next? #=> true p e.next #=> 1 p e.next? #=> true p e.next #=> 2 p e.next? #=> true p e.next #=> 3 p e.next? #=> false p e.next #raises StopIteration
I propose the method to be called
next? as it returns either
I am aware that we can currently figure out if there is a next value by using
rescue (as in the code snippet above), but it is ugly since it covers many lines and uses exceptions for control flow.
next? method makes enumerators a little nicer to work with.
A patch with an example implementation for ruby trunk is attached (in git-diff format, any feedback welcome).
I agree that my patch will be licensed under the Ruby License.
Updated by shevegen (Robert A. Heiler) over 3 years ago
I guess we have to wait how matz feels about it, that is, .next? in
this context. I personally have no problem with it - I wanted to
say something to this, though:
I am aware that we can currently figure out if there is a next
value by using rescue (as in the code snippet above), but it
is ugly since it covers many lines and uses exceptions for
I think you were not the first one here to want to avoid using
exceptions for control flow; there is also some other issue request
about worker/queue, which is a bit similar to what you suggested
here, if I understood it correctly so, which also avoids begin/rescue.
The ability to "look into the future" and ask ruby whether this or
that is ok, without depending on begin/rescue control flow, in regards
to methods. I think the one who suggested it was asking so in anticipation
as to whether an ArgumentError will be triggered, if this or that input
parameter is used.
I found it interesting because it is a bit of a mix between
runtime-introspection, and also somewhat similar to begin/rescue,
just without ... using begin/rescue. :)
But I think it's best to see how matz feels it may interconnect
with other ruby features (your proposal is of course simpler and
different than what I wrote just now; I just wanted to provide
a slightly different context, since I found it similar - some
ruby people preferring to avoid begin/rescue and I think that