Michel Fortin:
> But what about the "case 1: ... case 10:" syntax?

You are right, I think we have to make an exception on this then, and consider that range a single entity.
(You have just found an example why a conceptually messed up syntax (like that ranged one) always comes to bite us in the butt sooner or later.)

Bye,
bearophile

Michel Fortin:
> But what about the "case 1: ... case 10:" syntax?
> 
> 	switch (x) {
> 		case 1: .. case 10:
> 		case 22: .. case 32:
> 		case 52, 64:
> 			doSomething();
> 			break;
> 		default:
> 			whatever();
> 			break;
> 	}

Sorry, in my first answer I have a bit partially misunderstood your question.
You can write that like this, but I think this is not compatible with the current syntax (after commas you can of course add a newline):

case 1: .. case 10, case 22: .. case 32, 52, 64:

Otherwise you can keep them splitted (this needs no syntax changes):

                case 1: .. case 10: goto case;
                case 22: .. case 32: goto case;
                case 52, 64:

One of my original proposals was this, that now can not be used: case 1 ... 10, 22 ... 32, 52, 64:

Bye,
bearophile

On 06/20/2010 09:00 PM, bearophile wrote:
> Michel Fortin:
>> But what about the "case 1: ... case 10:" syntax?
>>
>> 	switch (x) {
>> 		case 1: .. case 10:
>> 		case 22: .. case 32:
>> 		case 52, 64:
>> 			doSomething();
>> 			break;
>> 		default:
>> 			whatever();
>> 			break;
>> 	}
>
> Sorry, in my first answer I have a bit partially misunderstood your question.
> You can write that like this, but I think this is not compatible with the current syntax (after commas you can of course add a newline):
>
> case 1: .. case 10, case 22: .. case 32, 52, 64:
>
> Otherwise you can keep them splitted (this needs no syntax changes):
>
>                  case 1: .. case 10: goto case;
>                  case 22: .. case 32: goto case;
>                  case 52, 64:
>
> One of my original proposals was this, that now can not be used:
> case 1 ... 10, 22 ... 32, 52, 64:

The intent is to only require a control flow transfer if there is at least one statement after the label.

Andrei

Hello Andrei,

> On 06/20/2010 09:00 PM, bearophile wrote:
> 
>> Michel Fortin:
>> 
>>> But what about the "case 1: ... case 10:" syntax?
>>> 
>>> switch (x) {
>>> case 1: .. case 10:
>>> case 22: .. case 32:
>>> case 52, 64:
>>> doSomething();
>>> break;
>>> default:
>>> whatever();
>>> break;
>>> }
>> Sorry, in my first answer I have a bit partially misunderstood your
>> question.
>> 
>> You can write that like this, but I think this is not compatible with
>> the current syntax (after commas you can of course add a newline):
>> 
>> case 1: .. case 10, case 22: .. case 32, 52, 64:
>> 
>> Otherwise you can keep them splitted (this needs no syntax changes):
>> 
>> case 1: .. case 10: goto case;
>> case 22: .. case 32: goto case;
>> case 52, 64:
>> One of my original proposals was this, that now can not be used: case
>> 1 ... 10, 22 ... 32, 52, 64:
>> 
> The intent is to only require a control flow transfer if there is at
> least one statement after the label.

Anyone who fails to include that special case in there proposal should have there hard drive reformatted, with soap.

http://www.youtube.com/watch?v=Ktzt096mlxs


-- 
... <IXOYE><

Andrei:

>The intent is to only require a control flow transfer if there is at least one statement after the label.<

The current switch syntax is already very hairy (even lot of people on this newsgroup are ignorant about some parts of it!) and it contains one or more special cases. So I suggest to avoid adding one more special case. Special cases are bad.

Bye,
bearophile

bearophile wrote:
> Andrei:
> 
>> The intent is to only require a control flow transfer if there is at least one statement after the label.<
> 
> The current switch syntax is already very hairy (even lot of people on this newsgroup are ignorant about some parts of it!) and it contains one or more special cases. So I suggest to avoid adding one more special case. Special cases are bad.

You seem to be doing the best you can to torpedo this proposal by adding an extra requirement to it, which is both painful and useless.
Please stop now.

On Jun 21, 10 17:52, bearophile wrote:
> Andrei:
>
>> The intent is to only require a control flow transfer if there is at least one statement after the label.<
>
> The current switch syntax is already very hairy (even lot of people on this newsgroup are ignorant about some parts of it!) and it contains one or more special cases. So I suggest to avoid adding one more special case. Special cases are bad.
>
> Bye,
> bearophile

That is just C#'s switch syntax. And I don't see how the current switch syntax is "hairy".

KennyTM~ wrote:

> On Jun 19, 10 07:17, Jonathan M Davis wrote:
>> bearophile wrote:
>>
>>> 2) switch cases that don't end with goto or break:
>>>
>>> void main() {
>>>      int x, y;
>>>      switch (x) {
>>>          case 0: y++;
>>>          default: y--;
>>>      }
>>> }
>>
>> I, for one, _want_ case statements to be able to fall through. It would be horribly painful in many cases if they couldn't. Now, requiring a separate statement like fallthrough or somesuch instead of break might not be a bad idea, but requiring that each case end with a break would seriously restrict the usefulness of switch statements.
>>
>> - Jonathan M Davis
> 
> This "fallthrough" statement already exists.
> 
>      switch (x) {
>         case 0:
>           do_something();
>           goto case;
>         case 1:
>           do_more_thing();
>           goto case;
>         case 2:
>           done();
>           break;
>         default:
>           error();
>           break;
>      }

I forgot about that one. *Sigh* D has so many cool little features that sometimes it feels like I'm forgetting at least half of them. Oh well. It's silly to complain that D has too much cool stuff.

In any case, that means that it could be made required to have a control statement at the end of a case block without having to specify a specific destination for fallthrough - though I'd prefer "continue switch" over "goto case" since it's more explicit and less error prone (since there's no doubt that you didn't intend to put a destination for the goto if you use "continue switch" instead of a "goto case" without a destination). But we do have enough to make a control statement required without adding anything else to the language.

Thanks for pointing out that little detail of goto.

- Jonathan M Davis

KennyTM~:
> That is just C#'s switch syntax.

Some of the C# designers are people with a long experience in implementing (Pascal-like) programming languages. Convergent evolution is a way to confirm my idea was good, then :-)


>And I don't see how the current switch syntax is "hairy".<

Even if you aren't able to see it, it doesn't change the fact that D switch syntax is made by several enhancements (or even fixes, like the one currently discussed, and time ago in bugzilla I have asked for another fix to the switch syntax) over the C switch syntax that is quite unclean and unsafe to start with (see Duff's device for an example of how unclean it is, or the recently introduced "static switch" of D that patches a common bug source).
After about three years of using D I am able to forget that "goto case;" is a valid syntax. In another answer Jonathan M Davis says something similar:
>I forgot about that one. *Sigh* D has so many cool little features that sometimes it feels like I'm forgetting at least half of them. Oh well. It's silly to complain that D has too much cool stuff.<
When normal people forget or ignore parts of a basic language construct it means the language is very complex.
The recently introduced ranged case syntax can be handy, but it's not a clean thing.
So D switches are quite hairy. Somewhere we'll have to write a short list of the differences between D and C switches.

Bye,
bearophile

Jonathan M Davis Wrote:
> 
> In any case, that means that it could be made required to have a control statement at the end of a case block without having to specify a specific destination for fallthrough - though I'd prefer "continue switch" over "goto case" since it's more explicit and less error prone (since there's no doubt that you didn't intend to put a destination for the goto if you use "continue switch" instead of a "goto case" without a destination).

It's a small thing, but I think "continue switch" could be misleading.  Consider this:

switch (getState()) {
case X:
    setState(Z);
    continue switch;
case Y:
    break;
case Z:
    writeln( "done!" );
}

Having never encountered D before, what would be your interpretation of this code?