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
