Bug #11975: Range#last is not consistent and possibly does not do what is expected.

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: 2.3.0
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN

[ioquatix (Samuel Williams)]

The following example demonstrates an inconsistency with Range:

This is expected behaviour:

(0..10).last => 10
(0..10).to_a.last => 10

This is unexpected behaviour:

(0...10).last => 10 # (should be 9?)
(0...10).to_a.last => 9

I believe that Range#last should give the last valid value for a range. Discussion?

[marcandre (Marc-Andre Lafortune)]

• Status changed from Open to Rejected

This is intentional and documented:

"Note that with no arguments +last+ will return the object that defines the end of the range even if #exclude_end? is +true+."

Changing that would create incompatibilities that would far outweigh any benefit (if any).

[nobu (Nobuyoshi Nakada)]

Range is not only for discrete values.
What will you expect for (0.0...1.0).last?

[ioquatix (Samuel Williams)]

Nakada-san, (0.0...1.0).last would probably give the same error as (0.0...1.0).to_a?

Marc, even though it's intentional, and even documented, it's still not obvious that this is desirable behaviour. What I did find, is an equivalent method, max, which does do what I needed. I know practically speaking that this is not possible to fix this issue. Perhaps the best course of action would be to (a) not do anything or (b) deprecate last since it's behaviour is confusing and there are several alternatives.

[noniq (Stefan Daschek)]

I haven't found this behaviour surprising at all. Maybe it’s because I'm
almost always using literal ranges and this lead me to think of
Range#last as “give me the last element of the range’s definition
(regardless of exclude_end?)”, i.e. I expect (0...1).last to behave
like [0, 1].last.

Am 12.01.16 um 10:08 schrieb [e-mail]:

Issue #11975 has been updated by Samuel Williams.

Nakada-san, (0.0...1.0).last would probably give the same error as (0.0...1.0).to_a?

Marc, even though it's intentional, and even documented, it's still not obvious that this is desirable behaviour. What I did find, is an equivalent method, max, which does do what I needed. I know practically speaking that this is not possible to fix this issue. Perhaps the best course of action would be to (a) not do anything or (b) deprecate last since it's behaviour is confusing and there are several alternatives.

---

Bug #11975: Range#last is not consistent and possibly does not do what is expected.
https://bugs.ruby-lang.org/issues/11975#change-56059

• Author: Samuel Williams
• Status: Rejected
• Priority: Normal
• Assignee:
• ruby -v: 2.3.0
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN

---

The following example demonstrates an inconsistency with Range:

This is expected behaviour:

(0..10).last => 10
(0..10).to_a.last => 10

This is unexpected behaviour:

(0...10).last => 10 # (should be 9?)
(0...10).to_a.last => 9

I believe that Range#last should give the last valid value for a range. Discussion?

Unsubscribe: mailto:[e-mail]?subject=unsubscribe
http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core