Project

General

Profile

Bug #11975

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

Added by ioquatix (Samuel Williams) almost 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:72800]

Description

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?

History

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

  • 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).

Updated by nobu (Nobuyoshi Nakada) almost 4 years ago

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

Updated by ioquatix (Samuel Williams) almost 4 years ago

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.

Updated by noniq (Stefan Daschek) almost 4 years ago

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 samuel@oriontransfer.org:

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: ruby-core-request@ruby-lang.org?subject=unsubscribe
http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core

Also available in: Atom PDF