Feature #14084: Introduce Enumerator#next?

• Status: Open
• Assignee: -
• Target version: -

[tessi (Philipp Tessenow)]

I'd like to propose a new method for Enumerator which returns whether there will be a next value in the enumerator when calling Enumerator#next.

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 true or false.
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.
Introducing the 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.

[tessi (Philipp Tessenow)]

• Description updated (diff)

[tessi (Philipp Tessenow)]

• Subject changed from Add Enumerator#next? to Proposal: Add the method Enumerator#next?

[tessi (Philipp Tessenow)]

• Subject changed from Proposal: Add the method Enumerator#next? to Proposal: Introduce Enumerator#next?

[tessi (Philipp Tessenow)]

• Subject changed from Proposal: Introduce Enumerator#next? to Introduce Enumerator#next?

[shevegen (Robert A. Heiler)]

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
control flow.

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
is understandable).

[tessi (Philipp Tessenow)]

• Description updated (diff)

edited the code example to be a little more readable as to michael's suggestion (https://twitter.com/__michaelg/status/927541360764342272)