Sean Kelly:
> Having never encountered D before, what would be your interpretation of this code?

Unfortunately the "continue case;" syntax looks about equally unintuitive to me :-(

Bye,
bearophile

Andrei Alexandrescu wrote:
> On 06/19/2010 06:58 AM, Don wrote:
>> Andrei Alexandrescu wrote:
>>> Don wrote:
>>> [snip]
>>>> Or is too late to break backwards compatibility with B ?
>>>
>>> We can and should do it. It won't impact TDPL adversely.
>>
>> Excellent! I'll make a patch for it when I have time.
> 
> Walter just gave the green light, so Don - it's up to you.

I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B.

On 06/21/2010 01:27 PM, Sean Kelly wrote:
> 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?

Well looks pretty good to me to be honest.

Andrei

On 06/21/2010 03:08 PM, Don wrote:
> Andrei Alexandrescu wrote:
>> On 06/19/2010 06:58 AM, Don wrote:
>>> Andrei Alexandrescu wrote:
>>>> Don wrote:
>>>> [snip]
>>>>> Or is too late to break backwards compatibility with B ?
>>>>
>>>> We can and should do it. It won't impact TDPL adversely.
>>>
>>> Excellent! I'll make a patch for it when I have time.
>>
>> Walter just gave the green light, so Don - it's up to you.
>
> I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code
> written by at least 4 different people. I think everyone gets stung by
> that B.

This is pretty amazing. Can't wait to see the checkin!

It might be interesting to see how many bugs are caught by restricting the switch statement.


Andrei

Don:
> I patched my DMD. Quite successful. It caught 8 bugs in Phobos, in code written by at least 4 different people. I think everyone gets stung by that B.

Thank you Don.

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 06/21/2010 01:27 PM, Sean Kelly wrote:
>> 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?
> 
> Well looks pretty good to me to be honest.

So would you say "done!" is printed or not?

On 06/21/2010 03:46 PM, Sean Kelly wrote:
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> On 06/21/2010 01:27 PM, Sean Kelly wrote:
>>> 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?
>>
>> Well looks pretty good to me to be honest.
>
> So would you say "done!" is printed or not?

I say it isn't because the switch predicate is only evaluated once and if you change it after evaluation it doesn't matter.

*Placing bet of 5 pixels*

Oh, wait, does 'continue switch' go back up to the top like what continue does in a loop?

*quietly withdraws bet*

Sean Kelly wrote:

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

I hadn't thought of that. That could be a source of confusion. However, since a switch statement isn't a loop, and it's not a construct in any other language AFAIK, the person will look it up. Once you've looked it up, I don't think that it would be particularly hard to remember what it actually does. It's quite clear what's going once you've become familiar with the construct and is quite unambiguous in comparison to "goto case" which could easily be missing the target case rather than being meant for fallthrough.

So, perhaps it's not immediately intuitive, but many language constructs are, and I think that it's fairly clear once you've looked it up. Having something like "fallthrough" or "goto next case" would of course be even clearer, but those would require new keywords. I still think that "continue switch" would be clearer than "goto case" as well as less error prone. Personally, I think that the fact that it's less error prone alone makes it a better choice even if it were somewhat less clear.

- Jonathan M Davis

On 06/21/2010 03:46 PM, Sean Kelly wrote:
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> On 06/21/2010 01:27 PM, Sean Kelly wrote:
>>> 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?
>>
>> Well looks pretty good to me to be honest.
>
> So would you say "done!" is printed or not?

I'd say "continue switch" does not reevaluate getState() because switch is not a looping statement. So I'd think it simply continues down, so writeln is not printed.

But I realize I am biased.

Andrei

Jonathan M Davis wrote:
> Sean Kelly wrote:
> 
>> 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?
> 
> I hadn't thought of that. That could be a source of confusion. However, since a switch statement isn't a loop, and it's not a construct in any other language AFAIK, the person will look it up. Once you've looked it up, I don't think that it would be particularly hard to remember what it actually does. It's quite clear what's going once you've become familiar with the construct and is quite unambiguous in comparison to "goto case" which could easily be missing the target case rather than being meant for fallthrough.
> 
> So, perhaps it's not immediately intuitive, but many language constructs are, and I think that it's fairly clear once you've looked it up. Having something like "fallthrough" or "goto next case" would of course be even clearer, but those would require new keywords. I still think that "continue switch" would be clearer than "goto case" as well as less error prone. Personally, I think that the fact that it's less error prone alone makes it a better choice even if it were somewhat less clear.
> 
> - Jonathan M Davis

But 'goto case XXX' is an extremely rarely encountered construct, that screams 'Examine this code closely'. So I don't think it needs extra error checking.