Case Range Statement ..

[Andrei Alexandrescu]

Nick Sabalausky wrote:
> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
> news:h30845$2kla$2 at digitalmars.com...
>> bearophile wrote:
>>> Walter Bright Wrote:
>>>> I like:
>>>>     a .. b+1
>>>> to mean inclusive range.
>>> Me too, but does it work when the upper interval is int.max, char.max, 
>>> ulong.max, ucent.max, etc?
>> Nope. Wrap around is always a special case, not just for ranges. It's in 
>> the nature of 2's complement arithmetic.
> 
> Suppose, hypothetically, that we did have a "right-inclusive-range" token. 
> At the moment I don't give a rat's ass what it actually is, '...', '..#', 
> 'poopiesOnAFlyingStick', whatever. Now, as has been pointed out far to many 
> times by now to still not get:
> 
> a .. int.max+1   // wraparound breaks it
> a right_inclusive_range_tok int.max    // works fine, wraparound isn't even 
> relevant.

Writing an inclusive e.g. loop that goes all the way to the largest 
integers is tricky no matter what. So this is not a problem with open 
ranges. Open ranges are there for a good reason.

> And another problem people have already pointed out numerous times with 
> making "a .. b+1" the inclusive range syntax:
> 
> double a=1, b=5;
> // Let's make an inclusive range from 1.0 to 5.0!
> a .. b+1
> // Oh look! 5.5f is in the range! It didn't f*^* work!

b+1 is correct if the range is iterated by 1, as in foreach or as an 
array index. That's what Walter meant because that's what's in the 
language. If you want to define a floating-point range that is closed to 
the right, you may want to use an open range from a to nextUp(b). The 
nextUp function (defined in std.math by Don I think) returns the very 
next floating point value. That's exactly what I do in std.random.

> And yet another:
> float a=1, b=somethingReallyLarge;
> assert(b+1 == b);
> // Let's make an inclusive range!
> a .. b+1
> // Oh look! b is missing from the range! It didn't f*^* work again!

This is not a problem with ranges. It's an issue inherent to 
floating-point arithmetic.

> "a .. b+1" as *the* inclusive range is just plain broken. There is no "Yea, 
> but...!" that can change that.

Yeah, but nextUp.

> And while I'm ranting, why in the world is anyone defending the continued 
> existance of "5." and ".5"? "Because it's already there and it basically 
> still works and isn't hurting anyone." Well it seems to be hurting the 
> adoption of an inclusive range that actually works. I thougt the point of D 
> was to clean up useless cruft like that, even if it still works (header 
> files) to make way for better approaches.

There is no need for a right-closed range in the language. It can be 
defined with ease as a library, although I'm not finding myself in need 
of one.


Andrei