Project

General

Profile

Actions

Feature #16822

closed

Array slicing: nils and edge cases

Added by zverok (Victor Shepelev) almost 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:98093]

Description

(First of all, I understand that the proposed change can break code, but I expect it not to be a large amount empirically.)

I propose that methods that slice an array (#slice and #[]) and return a sub-array in the normal case, should never return nil. E.g.,

ary = [1, 2, 3]
    1. Non-empty slice--how it works currently
a[1..2] # => [2, 3]
a[1...-1] # => [2]
    1. Empty slice--how it works currently
a[1...1] # => []
a[3...] # => []
a[-1..-2] # => [] 
    1. Sudden nilwhat I am proposing to change
a[4..] # => nil 
a[-10..-9] # => nil 

I believe that it would be better because the method would have cleaner "type definition" (If there is nothing in the array at the requested address, you'll have an empty array).

Most of the time, the empty array doesn't require any special handling; thus, ary[start...end].map { ... } will behave as expected if the requested range is outside of the array boundary.

It is especially painful with off-by-one errors; for an array of three elements, if ary[3...] (just outside the boundary) is [] while a[4...] (one more step outside) is nil, it typically results in some nasty NoMethodError for NilClass.

A similar example is ary[1..].reduce { } (everything except the first element--probably the first element was used to construct the initial value for reducing) with ary being non-empty 99.9% of the times. Then you meet one of the 0.1% cases, and instead of no-op reducing nothing, NoMethodError is fired.


Related issues 1 (0 open1 closed)

Has duplicate Ruby master - Bug #18741: Slicing an Array using index out of range inconsistent return typeRejectedActions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0