About switch case statements...

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Mon, Nov 16, 2009 at 9:30 AM, KennyTM~ <kennytm at gmail.com> wrote:
>> On Nov 17, 09 01:12, Bill Baxter wrote:
>>> On Mon, Nov 16, 2009 at 8:24 AM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org>  wrote:
>>>> Walter Bright wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>>> I was hoping the lesson learned would be to fix switch as was
>>>>>> suggested.
>>>>> I checked, because it wasn't written in the way I usually write things,
>>>>> and sure enough it wasn't code I wrote :-)
>>>>>
>>>>>  From the changelog for D 0.129: "Incorporated Ben Hinkle's new
>>>>> std.format
>>>>> which can print general arrays."
>>>>>
>>>>> http://www.digitalmars.com/d/1.0/changelog1.html#new0129
>>>> So people are liable to make the mistake.
>>>>
>>>> Andrei
>>>>
>>> What about when you want to fall through to a multiple label?  Or a range
>>> label?
>>>
>>> case 0:
>>>     // do stuff
>>>     goto case ??;
>>> case 1: .. case 9:
>>>      // do more stuff
>>>      goto case ??;
>>> case 10,20,30:
>>>      // still more stuff
>>>
>>> The obvious answer would seem to be just "pick any one".
>>> I just bring it up because I haven't seen that ... uh case ...
>>> mentioned by anyone.
>>>
>>> --bb
>> Since
>>
>> case a:
>> ..
>> case b:
>>
>> expands to
>>
>> case a:
>> case a+1:
>> case a+2:
>> // ....
>> case b:
>>
>> and
>>
>> case a,b,c,d:
>>
>> expands to
>>
>> case a:
>> case b:
>> case c:
>> case d:
>>
>> Your speculation is correct. Please note that the "goto case X;" statement
>> works *now*, so there's no need to guess its behavior.
> 
> Seriously?  Didn't realize.
> 
> So valid end-of-case statements would be:
>    break;
>    return;
>    continue;
>    goto *;
>    goto case *;
> And if you don't have one of those then it's an error?

throw *;


> Could this get into difficult-to-verify territory?  And therefore be
> difficult to implement?
> It looks like the exact same problem as enforcing that all code paths
> return a value, which is something I think D doesn't currently enforce
> because it's too hard.   So you run into Walter's dislike for
> errors/warnings that are incorrect because the compiler is too stupid.

It could enter difficult territory if the rule was:

if (condition) break;

and leave it to the compiler to prove that condition is always true. 
That's not the case with the proposed change. All control flow 
statements you enumerated above transfer flow unconditionally.


Andrei