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];

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.

Now a FAQ entry!

http://www.digitalmars.com/d/2.0/faq.html#case_range

Walter Bright wrote:
> I'm tired of typing this multiple times, so please indulge me while I cut & paste from one of them:

I don't mean to frustrate. I thought it may be in at least on of those replies but I think it deserves it's own subject.

> Having a very different meaning means it should have a distinctly different syntax.

I agree there in many ways but D doesn't really follow the rule for example:

static import bar;   //must use fully qualified name
static int i;        //persistent across calls
static void foo() {} //member of class rather than instance

have you considered a syntax that is radically different from case FirstExp : .. case LastExp : like many of the posts in announce have suggested

Walter Bright wrote:
> Now a FAQ entry!
> 
> http://www.digitalmars.com/d/2.0/faq.html#case_range

But it only explains the inclusive/exclusiveness and not any of the other points. Do you not agree that the syntax looks a little ugly?

And heeeeere we go again!

*sigh*

> switch( foo )
> {
>     case 0:
>     ..
>     case 5:
>         blah();
>         break;
>
>     default:
>         bork();
> }

Doesn't look so bad, does it?  For the record, I think the current syntax is ugly.  But:

* it WORKS,
* it is reasonably distinct from all the other uses of ".." which have a
DIFFERENT MEANING,
* it has an easily-explained rationale: "the .. stands in for the case
labels you would have written."

Can we please, please stop the useless bike-shedding on this NG?  Yes, it's a bit ugly, but all the alternatives proposed have SEMANTIC issues with them, which is much worse.

On Tue, 07 Jul 2009 17:56:31 +1200, Tim Matthews wrote:

I want to try and using similar terminology to show that 'static' is used with the same principle.

> static import bar;   //must use fully qualified name

The module "owns" the members (functions, globals). Since the owner is the module you must ask the module for its use.

> static int i;    //persistent across calls

The function "owns" the variable. Rather than having each call to a function have the int i, all calls use the same one since the function owns it and not the call.

> static void foo() {} //member of class rather than instance

The class "owns" the function. Much like the previous one, the class instance doesn't own it, the class does, so all instances share the same thing.

> have you considered a syntax that is radically different from case FirstExp : .. case LastExp : like many of the posts in announce have suggested

I do believe they have, and do agree the syntax is a little... odd... but I think the alternatives have been turned down for good reason.

>  case FirstExp .. case LastExp :

Is nice, but I don't think removing the : really adds much, besides, Daniel Keep's shown form of writing it looks better with the : and ultimately better than the above form.

Tim Matthews wrote:
> But it only explains the inclusive/exclusiveness and not any of the other points.

Let's start with agreeing on why:

	case X..Y:

is not appropriate.

> Do you not agree that the syntax looks a little ugly?

I haven't seen any thing less ugly that is workable.

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.

> 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");

Whats the semantic issues with this:

case 1:
case 2:
case 3:

replaced with

case (1,3):

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.