Bug #14699: Subtle behaviors with endless range

• Status: Closed
• Assignee: -
• Target version: 2.6
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[mame (Yusuke Endoh)]

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

Range#max

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

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

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

[mame (Yusuke Endoh)]

• Related to Feature #12912: An endless range `(1..)` added

[marcandre (Marc-Andre Lafortune)]

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.

[naruse (Yui NARUSE)]

• Target version set to 2.6

Need to be discussed with mrkn before December.

[matz (Yukihiro Matsumoto)]

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

Matz.

[mame (Yusuke Endoh)]

• 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]

[mame (Yusuke Endoh)]

• Related to Bug #18983: Range#size for beginless Range is not nil. added