Feature #4541: Inconsistent Array.slice()

• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)

The fix may be following but it can be a spec...

diff --git a/array.c b/array.c index bdeb768..4721387 100644

a/array.c

+++ b/array.c @@ -948,7 +948,7 @@ rb_ary_subseq(VALUE ary, long beg, long len)

{
    VALUE klass;

- if (beg > RARRAY_LEN(ary)) return Qnil;

if (beg >= RARRAY_LEN(ary)) return Qnil;

if (beg < 0 || len < 0) return Qnil;

if (RARRAY_LEN(ary) < len || RARRAY_LEN(ary) < beg + len) {

Hi,

On Tue, Apr 5, 2011 at 3:04 AM, Yui NARUSE <[e-mail]> wrote: > > Issue #4541 has been updated by Yui NARUSE. > > Status changed from Open to Assigned > Assignee set to Yukihiro Matsumoto > > The fix may be following but it can be a spec... > > diff --git a/array.c b/array.c > index bdeb768..4721387 100644 > --- a/array.c > +++ b/array.c > @@ -948,7 +948,7 @@ rb_ary_subseq(VALUE ary, long beg, long len) >  { >     VALUE klass; > > -    if (beg > RARRAY_LEN(ary)) return Qnil; > +    if (beg >= RARRAY_LEN(ary)) return Qnil; >     if (beg < 0 || len < 0) return Qnil; > >     if (RARRAY_LEN(ary) < len || RARRAY_LEN(ary) < beg + len) {

With all due respect, I am strongly opposed to that change. There is no way that the following results should change:

array[0...3] # => ["a", "b", "c"]
array[1...3] # => ["b", "c"]
array[2...3] # => ["c"]
array[3...3] # => [], as it *must* be.

The only possible change would be that array[42..42] returns [] instead of nil. For consistency's sake, `String#slice` would also have to be changed. I am not in favor of that change either, for compatibility reason and because I feel the current API makes sense. See my comment on issue #4245 [ruby-core:34197]. This issue is a duplicate of #4245.

I don't see the advantage of having nil returned in any case since the empty array already expresses the "there is no object in that range".

Out of bound can be tested separately if necessary, but most of the cases you just want to get a range and a resulting array. Having also nil being returned means that you need some more code to test return.nil? && return.empty?

• Target version changed from 1.9.2 to 1.9.3

This is not a bug. I'm against the spec change of this behavior.

Nobuyoshi, could you explain why you don't find the current behavior confusing and would like to keep it as it is? What would be a useful use case for the current implementation?

This discussion might help explain the rational for the current behavior: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/380636 There is also a related rationale in this posting: http://www.phwinfo.com/forum/comp-lang-ruby/462990-array-index-length-strange-behaviour.html#post2148794

• Tracker changed from Bug to Feature

• Category set to core
• Target version changed from 1.9.3 to 2.0.0

Changing to "feature" as this is a spec change. As I stated earlier, I'm against either propositions.

What I think is less confusing is to always return an array when passing ranges, like the following example: <pre> [][1..2] #=> [] instead of nil </pre> Think in some practical method like this one: <pre> def some_method(*elements) # suppose elements can be [], maybe elements are read from some file... special_element = args[0] # suppose we don't want elements.shift because we will send elements to another method... do_something_special if special_element elements[1..-1].each{|el| ...} # this will raise an exception if elements == [] call_another_method(elements) end </pre> Yes, I know this is not a great example, but I'm too tired right now to think in a better one...

I better remove my previous comment, it was not a good idea. I agree that there seem to be an inconsistency between `[1,2,3][3..1] # => []` and `[1,2,3][4..1] # => nil`. In my opinion, the confusion about the behavior of `Array#slice` could be coming from the difficulties in choosing good definitions for `Range` and `Array`. For example, the ranges `(3..1)`, `(4..1)`, `(1..-1)` all have no elements, but can be used to slice an array, all in different ways. It could be easier if there existed only one empty range: `(2..1) == (1..-1) and (2..1) == (1...1) and (2..1) == ('z'..'a') # => true`. But then there would come the problem of not being able to slice an array from the beginning and the end simultaneously with `a[1..-2]`. This can be resolved by introducing `RelativeRange` and `RelativeNumber` and do like this: `a[1.from_bottom..(-1).from_top]`. (The method `#include?` would not be defined for `RelativeRange` and relative numbers with different "anchors" would not be comparable; "anchor" would be an arbitrary symbol, like `:top` or `:bottom`.) Just an idea. To me, array is an object between string and hash, so how about viewing array as a special kind of hash, where only integer keys are allowed, and the keys come in pairs (`[1,2,3][1] == [1,2,3][-2]`), and think from there? (Strings should not probably be viewed as hash because splitting into characters is not very well defined for accented or otherwise decorated strings.) These are just my ideas. -Alexey. Update: i made a feature request #5534 for RelativeNumeric and RelativeRange. Last edited 2011-11-01