From: Charles Comstock <cc1@...>
Date: 2004-10-05T10:09:52+09:00
Subject: Re: [RCR] New [] Semantics

Bill Atkins wrote:
> Currently, the following code
> 
>    a = [1, 2, 3, 4, 5]
>    a[0, 3]
> 
> returns
> 
>    [1, 2, 3]
> 
> This is somewhat counter-intuitive.  Since Ruby has a built-in range
> type, [] ought to take advantage of it.  I propose that the []
> operators be redefined so that this behavior can only be achieved by
> explicitly providing a Range, e.g.  a[0...3].  The original code would
> then work like #values_at and return [1, 3].
> 

Yes but [start,length] is capable of expressing ranges that make no 
sense using [range].  For instance:

a = [:a,:b,:c,:d,:e,:f,:g,:h]
a[-2,2] # => [:g,:h]
a[-2..2] # => []
a[-2..-1] # => [:g, :h]
a[0..-1] # => [:a,:b,:c,:d,:e,:f,:g,:h]

Obviously it isn't too hard to convert between the two formats, but many 
times it makes far more sense to express it in the [start,length] format 
as opposed to the range format of start..end.

> Also, I don't know what happened with the earlier mention about the
> confusion between .. / ... but I'm a supporter of getting rid of '...'
> and just making .. inclusive.  Exclusive ranges can be represented
> with 0..(n + 1) if necessary.  I don't know if this is appropriate for
> an RCR.
> 

This makes perfect sense when the range is over numeric values, but to 
me ("a"..("c".succ)) is ugly and not easily read.  Or any other range of 
objects like that for that matter.

Charles Comstock