Is there ANY chance we can fix the bitwise operator precedence rules?

[Jonathan M Davis]

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