[ruby-core:51162] [ruby-trunk - Bug #7626][Rejected] Bizarre Array#fetch behavior with a block when index is out of bounds

Issue #7626 has been updated by marcandre (Marc-Andre Lafortune).

Status changed from Open to Rejected

`fetch(val){block}` either returns the requested value or yields to the block and return that result. The block is thus called only if the requested index is out of range and the argument is always the index.
----------------------------------------
Bug #7626: Bizarre Array#fetch behavior with a block when index is out of bounds
https://bugs.ruby-lang.org/issues/7626#change-35113

Author: Nevir (Ian MacLeod)
Status: Rejected
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: ruby 1.9.3p125 (2012-02-16 revision 34643) [x86_64-darwin12.1.0]


This also occurs on Ruby 1.8.

First, the example, taken almost directly from the docs (except the docs only describe the fetch(4) case):

irb(main):001:0> a = [11, 22, 33, 44]
=> [11, 22, 33, 44]
irb(main):002:0> a.fetch(0) { |i| i }
=> 11
irb(main):003:0> a.fetch(1) { |i| i }
=> 22
irb(main):004:0> a.fetch(2) { |i| i }
=> 33
irb(main):005:0> a.fetch(3) { |i| i }
=> 44
irb(main):006:0> a.fetch(4) { |i| i }
=> 4

This is incredibly bizarre and inconsistent behavior:

* The docs suggest (but do not confirm) that the block should always be given the index

* Without already having knowledge of whether the index is in or out of bounds, you can't differentiate between whether the block was given an index or a value.  (Unless you can key off of type information)

* What use case does the current behavior even solve?

It seems like the block should be given consistent arguments regardless of the index asked for: either the index (pointless), or the value (better) or both (best?).  Or just deprecate this block behavior alltogether.  Does anyone use it?


-- 
http://bugs.ruby-lang.org/