Andrei Alexandrescu wrote:
> 
> Prepare to be surprised. Compile this:
> 
> void main()
> {
>     switch (2)
>     {
>     case (1, 2): break;
>     default: break;
>     }
> }
> 
> 

I'm getting the message that it is impossible to override what is already and expression evaluating to the last in the comma sequence which is not the case as other meanings exist for function calls and templates etc.

Not surprising that it currently picks the default of just the expression in anyway and it would probably be in error if it didn't currently do so.

On Tue, 07 Jul 2009 04:35:56 -0400, 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=-

to? really, no, it needs to be -

switch (var) {
    case 0:
        break;

    case 1 - 5:
        break;
}

Jesse Phillips wrote:
> On Tue, 07 Jul 2009 04:35:56 -0400, 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=-
> 
> to? really, no, it needs to be -
> 
> switch (var) {
>     case 0:
>         break;
> 
>     case 1 - 5:
>         break;
> }

Is that a joke?

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

On Tue, Jul 7, 2009 at 9:07 AM, Bill Baxter<wbaxter@gmail.com> wrote:
> On Tue, Jul 7, 2009 at 5:24 PM, Tim Matthews<tim.matthews7@gmail.com> wrote:
>> Andrei Alexandrescu wrote:
>>>
>>> Existing actual or perceived inconsistencies are not an argument for adding more of them.
>>>
>>
>> Seriously?
>
> d00d.

Woah woah woah woah.  Who *are* you; superdan?  ;)

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

Andrei Alexandrescu, el  7 de julio a las 10:19 me escribiste:
> Token meaning has ALWAYS depended on context. ALWAYS.

I can use the exact same argument for using case X..Y: then =)

At least let's agree one is as arbitrary as the other... I can live with that syntax if you (people who likes case X: .. case Y: is better) accept that is just a cosmetic issue and you like your syntax better (and since who make the decisions likes it better, it will stay like that).

Can you at least use:
case X:
..
case Y:

in the examples/documentation/specs? I think most case X: .. case Y: haters found that format pretty acceptable, so we can all be a little happier =)

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

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  7 de julio a las 10:19 me escribiste:
>> Token meaning has ALWAYS depended on context. ALWAYS.
> 
> I can use the exact same argument for using case X..Y: then =)

You could, but it would be much more of a stretch. This is because expression1..expression2 is already a grammatical construct, so we're not talking only about one token anymore.

> At least let's agree one is as arbitrary as the other...

No. I don't agree at all.

> I can live with
> that syntax if you (people who likes case X: .. case Y: is better) accept
> that is just a cosmetic issue and you like your syntax better (and since
> who make the decisions likes it better, it will stay like that).

"case X: .. case Y:" is a cosmetic issue over e.g "case X .. case Y:" but is worlds better than "case X .. Y" and most or all other suggested syntaxes.

> Can you at least use:
> case X:
> ..
> case Y:
> 
> in the examples/documentation/specs? I think most case X: .. case Y:
> haters found that format pretty acceptable, so we can all be a little
> happier =)

To me they look the same, but if people are happier with wasting vertical space, sure.


Andrei

On Tue, 07 Jul 2009 11:01:12 -0500, Andrei Alexandrescu wrote:

> To me they look the same, but if people are happier with wasting vertical space, sure.

I think I've finally worked out why I don't like this syntax. Consider this ...


   switch (X) {
      case 1: funcA(); break;
      case 2,5,7,10 .. 17, 24, 32: funcB(); break;
      case 3,6,8,18 .. 23: funcC(); break;
   }

In other words, allowing a range of value inside a list of values.

How is this possible in today's D?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Wed, Jul 08, 2009 at 02:48:31AM +1000, Derek Parnell wrote:
>    switch (X) {
>       case 1: funcA(); break;
>       case 2,5,7,10 .. 17, 24, 32: funcB(); break;
>       case 3,6,8,18 .. 23: funcC(); break;
>    }
> In other words, allowing a range of value inside a list of values.
> 
> How is this possible in today's D?

switch(X) {
	case 1: stuff; break;
	case 2,5,7: case 10: .. case 17: case 24,32: stuff; break;
	case 3,6,8: case 18: .. case 23: stuff; break;
}

This compiles on the new dmd. Only one item is allowed on a case range, but you can just use fall through behaviour to make it its own case right after the list.




-- 
Adam D. Ruppe
http://arsdnet.net