Case Range Statement ..

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Walter Bright, el  6 de julio a las 22:24 me escribiste:
>> Tim Matthews wrote:
>>> The case range statement is currently this
>>> case FirstExp : .. case LastExp :
>>> Would it be ambiguous to the compiler if it was
>>> case FirstExp .. case LastExp :
>>> or even
>>> case FirstExp .. LastExp :
>>> Considering that we can correctly identify a slice rather than decimal by just 
>>> giving it a priority:
>>> a = b[3..6];
>> I'm tired of typing this multiple times, so please indulge me while I cut & paste 
>> from one of them:
>>
>> Because
>>
>> 1.    case X..Y:
>>
>> looks like
>>
>> 2.    foreach(e; X..Y)
>> 3.    array[X..Y]
>>
>> yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and
>> (2) and (3) are exclusive of Y.
>>
>> Having a very different meaning means it should have a distinctly
>> different syntax.
> 
> I think this is a weak argument, because you are still using the ".."!

Various different expressions are using various other tokens giving them 
different meanings, and nobody blinks an eye.

> You're just adding extra chars in the mix which looks like syntactic noise
> to me.

Those make it clear at the first sight what the construct does.

> Why won't you think that case 5: .. case 10: is inclusive when
> foreach(e; 5 .. 10) is exclusive? I just don't get it...

Because:

a) People coming from C, C++, or Java would be used to the notion of 
iterating over right-open integral ranges from e.g. iterating over 
arrays using indexes.

b) When writing down case labels, nobody expects to write one down 
knowing it won't be effected.

> I think the ... operator makes perfect sense because it's more general,
> yo could use array[X...Y] and case X..Y: where appropriate.

Is Y a global? :o) (Trick question.)

> I have to confess that arranged like this:
> 
> switch (x)
> {
> case 5:
> ..
> case 10:
> // ..
> 
> }
> 
> doesn't look so bad though, but I think it could be easy to miss the ".."
> when reviewing the code and there is still the semantic issue you talk
> about the ".." operator being inconsistently inclusive and exclusive
> depending on the context.

How in the world can one miss ".." and not miss various other tokens?

Token meaning has ALWAYS depended on context. ALWAYS.


Andrei