Case Range Statement ..

Leandro Lucarella llucax at gmail.com
Tue Jul 7 07:55:57 PDT 2009


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 ".."!
You're just adding extra chars in the mix which looks like syntactic noise
to me.

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

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

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.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------



More information about the Digitalmars-d mailing list