Case Range Statement ..

[Daniel Keep]

Tim Matthews wrote:
> Daniel Keep wrote:
> would have written."
>>
>> Can we please, please stop the useless bike-shedding on this NG?
> 
> Rather than sift through replies to a release announcement (which I have
> done since first post and still have an answer) it deserves its own
> subject. The release announcement already has:
> 
> switch case range limits
> case fall through
> unsigned signed conversion
> build deps
> bugs
> others and plain old thanks for release
> 
> Sorry I must be really dumb for not understanding that subjects are a
> bad thing.

It's not that making a thread about a particular feature is bad.  This
*specific* feature has been discussed previously.  The whole "this is
ugly, why not X" has been done to death, with Walter and Andrei having
already given the reasons for choosing this syntax.  I don't especially
like `case a: .. case b:` aesthetically, either.  But I also haven't
seen any workable alternatives, and it's not as bad as some people seem
to think it is.

This community has a horrible tendency to become focused on bike-shed
issues and I really, really don't want to see this particular one start
up all over again.

>> all the alternatives proposed have SEMANTIC issues
>> with them, which is much worse.
> 
> Currently we can:
> 
> import foo.bar;
> 
> or
> 
> char[] fileData = cast(char[])import("file.txt");

How is this relevant?

If you're arguing that D already re-uses syntax in places to mean
slightly different things, that's because D isn't perfect and its
primary developer is a pragmatist.

If you're arguing that we have a keyword whose meaning changes based on
the presence or absence of parentheses, I'd point out that the first
form is semantically invalid if you add parentheses, whilst the second
is semantically invalid if you remove them.  Which brings me to...

> Whats the semantic issues with this:
> 
> case 1:
> case 2:
> case 3:
> 
> replaced with
> 
> case (1,3):

(1,3) is already a valid expression.  It evaluates to 3.  This would
introduce code which is valid in C and in D1, but which invisibly
changes meaning in D2; something Walter is very, very against.

To pre-empt the rest of this argument:

[1,3] is also a valid expression.  [1..3] already has a meaning in a
different part of the syntax.  (1..3) and 1..3 don't have any meaning
but look like [1..3] which is an EXCLUSIVE range, not an INCLUSIVE range
like a case range is.  [1...3] looks like a typo of [1..3], as does
1...3 and (1...3).  case 1 .. case 3: would probably work but at that
point you're arguing to remove a single colon which is just petty.