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

Existing actual or perceived inconsistencies are not an argument for adding more of them.

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

a) It is not arguably better and more suggestive than the syntax in place.

b) "(1,3)" already means two things, neither of which has anything to do with "I want to write case labels from 1 through 3 here".


Andrei

Walter Bright wrote:
> 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 we have to be so immature about this, it's an actual topic rather than the random trolls that have been posted by many here.

I was originally asking about the ambiguity of not having the extra colon but anyway:

Yes I agree double dot for case range is inconsistent with the double dot for range due to one being inclusive of the endpoint. berophile suggested using tripple dot in announce and he got "why?" as a reply. The "why" has already been posted but the "why not" hasn't yet people reply to me with "here we go again!".

Alternatively don't use dots.

I think the issue with the extra "case" and/ ";" needs to be treated differently. There or not the syntax may seem inconsistent to new D users.

Tim Matthews wrote:
> Walter Bright wrote:
>> 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 we have to be so immature about this, it's an actual topic rather than the random trolls that have been posted by many here.
> 
> I was originally asking about the ambiguity of not having the extra colon but anyway:

There is no ambiguity in removing the extra colon.

> Yes I agree double dot for case range is inconsistent with the double dot for range due to one being inclusive of the endpoint. berophile suggested using tripple dot in announce and he got "why?" as a reply.
> The "why" has already been posted but the "why not" hasn't yet people reply to me with "here we go again!".

My "why" embedded two longer comments:

a) Currently "..." ends something and ".." separates something, much like in natural language. His suggestion would have "..." separate something. Why?

b) Even if we ignore (a) for the moment, the "why" is legitimate at face value: we have a syntax that is implemented and works. Any change to the syntax should mark an improvement. Where is the improvement?

Just because it doesn't not work doesn't mean it must be adopted!

It has also been suggested in an earlier thread a range with ".." should mean open and a range with "..." should mean closed. I explained back then how that proposal was a complete disaster.

> Alternatively don't use dots.

How would that work? And... why?

> I think the issue with the extra "case" and/ ";" needs to be treated differently. There or not the syntax may seem inconsistent to new D users.

I swear if I didn't know anything about the feature and saw the syntax "case a: .. case b:" I'd know exactly what it does in a millisecond. Why would the syntax seem inconsistent to new D users? First of all, inconsistent with what? And how would you treat the issue differently?


Andrei

Andrei Alexandrescu wrote:
> I swear if I didn't know anything about the feature and saw the syntax "case a: .. case b:" I'd know exactly what it does in a millisecond. Why would the syntax seem inconsistent to new D users? First of all, inconsistent with what? And how would you treat the issue differently?
> 
> 
> Andrei

I think something that might help is if you started using the syntax like this:

> case a:
> ..
> case b:
>     blah

Now it's clear that it represents a sequence of case labels where all but the first and last have been elided VERSUS representing a case label where the label is a range.

I get the sneaking suspicion that the major problem people have with the syntax is that when you write "case a: .. case b:" all on one line, they treat it as the latter when they should be thinking in terms of the former; the various suggestions that have been made would seem to support this.

Andrei Alexandrescu wrote:

> 
> I swear if I didn't know anything about the feature and saw the syntax "case a: .. case b:" I'd know exactly what it does in a millisecond. Why would the syntax seem inconsistent to new D users? First of all, inconsistent with what? And how would you treat the issue differently?
> 
> 
> Andrei


When I said inconsistent I was agreeing with walter previously stated that it has a very different meaning. Because between the case and colons there is the double dot previously just used in range's start and 1 past endpoint.

In case range we include the endpoint.

We just now have an extra verbose syntax that would be great for minimizing ambiguity but instead is getting used to minimize inconsistency.

Tim Matthews wrote:
> Walter Bright wrote:
>> 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 we have to be so immature about this, it's an actual topic rather than the random trolls that have been posted by many here.

You did pose that case, and please forgive me for being a bit testy about it being repeatedly asked and answered.

> I was originally asking about the ambiguity of not having the extra colon but anyway:
> 
> Yes I agree double dot for case range is inconsistent with the double dot for range due to one being inclusive of the endpoint. berophile suggested using tripple dot in announce and he got "why?" as a reply. The "why" has already been posted but the "why not" hasn't yet people reply to me with "here we go again!".
>
> Alternatively don't use dots.

As for the "why not" of:

    case X .. case Y:

it's really the same reason that ; is used to terminate a statement. The ; is not strictly necessary, but it provides a nice anchor for parsing when things go wrong. You get a reasonably well targeted message with the right line number instead of something erratic.

As for the "why not" of ...:

... and .. are not visually very distinguishable, and frankly I can't see a compelling "why" for it.

Andrei Alexandrescu wrote:
> 
> Existing actual or perceived inconsistencies are not an argument for adding more of them.
> 

Seriously?

> 
> a) It is not arguably better and more suggestive than the syntax in place.

I can't guarantee that it's better but I do think an argument can prove a result. Thats what arguments for.

> 
> b) "(1,3)" already means two things, neither of which has anything to do 

Could you kindly state those?

I can see that just having "(1,3)" preceded with the "case" keyword makes most other meanings impossible.

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


Or you introduce a new keyword :-)

switch (var) {
    case 0:
        break;

    case 1 to 5:
        break;
}


-=mike=-

Mike James wrote:
> 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];
> 
> 
> Or you introduce a new keyword :-)
> 
> switch (var) {
>     case 0:
>         break;
> 
>     case 1 to 5:
>         break;
> }
> 
> 
> -=mike=-


Introducing "to" as a keyword would break the std.conv module, which would be a shame. It's a very nice module.

-Lars

"Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message news:h2uoju$5f1$1@digitalmars.com...
>
> 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.

I like bike sheds.