Case Range Statement ..

[Nick Sabalausky]

"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.

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!

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!

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

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.