Case Range Statement ..

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Wed, Jul 8, 2009 at 8:26 PM, Walter Bright<newshound1 at digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> I think what Jerome is getting at is that we could be getting more
>>> mileage out of the xpr1..xpr2 syntax.  It would be useful syntax for
>>> more than just integral, dense ranges in foreach and slices.  The
>>> equivalents I've used or seen in Ruby, Python and Matlab are more
>>> versatile than D's.  Perhaps that can't be translated in any useful
>>> way to a static language like D, I dunno.  But it leaves one with the
>>> feeling that D's slice literals are underpowered and that the case
>>> range thing is just plugging a hole in a dilapidated boat rather than
>>> building us a nice new sleek yacht.
>> How are python's so much better?
>>
>> 1. python's ranges are exclusive of the endpoint
>>
>> 2. python doesn't have a switch statement, so case ranges being better in
>> python makes no sense
> 
> 
> Not every one of those has every feature you could imagine.  But nice
> things about Python's slices include:
> * optional step size,
> * step size can be negative.
> * nice compact notation
> * And the a:b syntax maps to a slice object so that you can manipulate
> them and pass them around.
> 
> Ruby is the only one I mentioned that has both inclusive and exclusive
> ranges (using two dots for inclusive, three dots for exclusive).
> Matlab's are always inclusive.  But they all have an optional step
> size.  Python's are a little annoying in that, like D, you can't use
> them outside of indexing expressions.  Can't even use them in loops.
> In NumPy, the numerical library for Python, they've invented some
> quirky objects like numpy.r_ which you index to create a range
> literal.  Like
>   >>>   numpy.r_[0:4:0.5]
>   array([ 0. ,  0.5,  1. ,  1.5,  2. ,  2.5,  3. ,  3.5])
> You could do the same in D, but I don't think anyone in NumPy thinks
> of it as a particularly elegant way to make ranges (compared to matlab
> where just plain 0:4:0.5 gets you the same thing).  Also you'd most
> often like to have that 4.0 in there, so you have to tweak the range
> to be [0:4.5:0.5] to get that inclusivity, because python doesn't have
> inclusive ranges.  Not ideal.  So they also have
> 
> Anyway, you seem pretty satisfied with what you've got, so don't mind
> me.  You've got to draw the line somewhere.

Nevertheless, I think these all are great ideas for additions to std.range.

Andrei