Bug #14699

Subtle behaviors with endless range

Added by mame (Yusuke Endoh) almost 3 years ago. Updated over 2 years ago.

Target version:


Currently, some Range's methods behaves weirdly with endless range.


Range#max always returns nil. Is this okay, or is another result expected?

p (0..).max #=> nil
p (0..).max(3) #=> nil
p (0..).max {|a, b| a <=> b } #=> nil

Note that (0..).min {|a, b| a <=> b } gets stuck. I think Range#min and Range#max should behave the same if a block are passed, but I'm uncertain what behavior is preferable.


Range#last returns nil if no argument is passed. But it gets stuck if a length argument is passed. Is this okay?

p (0..).last #=> nil
p (0..).last(3) #=> stuck


Range#size returns nil for endless range. I think this is somewhat reasonable because ("a".."z").size returns nil.

Related issues

Related to Ruby master - Feature #12912: An endless range `(1..)`ClosedActions

Updated by mame (Yusuke Endoh) almost 3 years ago

Updated by marcandre (Marc-Andre Lafortune) almost 3 years ago

I believe (0..).max(3) and (0..).max {|a, b| a <=> b } can not return nil. They should either hang or (seems more useful) raise an error, same as min. I would have (0..).last(3) also raise an error.

(0..).size must return Float::INFINITY, not nil. The only reason why ("a".."z").size returns nil was that I was too lazy to code a valid calculation that handled all the strange corner cases of the way we iterate on strings.

Updated by naruse (Yui NARUSE) over 2 years ago

  • Target version set to 2.6

Need to be discussed with mrkn before December.

Updated by matz (Yukihiro Matsumoto) over 2 years ago

I agree with marcandre (Marc-Andre Lafortune) here. Let's raise exceptions.



Updated by mame (Yusuke Endoh) over 2 years ago

  • Status changed from Open to Closed

Applied in changeset trunk|r63715.

range.c: Range#size now returns Float::INFINITY if it is endless

Fixes [Bug #14699]

Also available in: Atom PDF