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

[Robert Jacques]

On Fri, 18 Jun 2010 20:23:45 -0400, Jonathan M Davis  
<jmdavisProg at gmail.com> wrote:

> bearophile wrote:
>
>> Jonathan M Davis:
>>> but requiring that each case end with a break would seriously restrict
>>> the usefulness of switch statements.
>>
>> Time ago there was a long thread about this topic (and in the meantime
>> Walter has added the "static switch" that burns the fat chance to add to
>> D2 a second safer switch that fixes both the common kind of bugs caused  
>> by
>> C switch statements and not just the enum-switch bugs avoided by the
>> current static switch!) and I am not sure it's right to restart that
>> discussion again. Anyway, can you show me one example where requiring  
>> that
>> each case end with a break OR goto restricts the usefulness of switch
>> statements?
>>
>> Bye,
>> bearophile
>
> Well, I would pount out that you mentioning it more or less reopens the
> discussion, but in any case, the simplest answer would be if you have
> multiple values for the variable that your switching on which should all  
> be
> using the same kind. Fortunately, D simplifies that by allowing you to  
> put
> multiple values with a single case. An extension of that is if you have  
> two
> cases which are almost identical but where one of them needs to do  
> something
> first before the code that is common between both cases.
>
> A more complicated example would be one where you're doing something like
> Duff's Device:
>
> send(to, from, count)
> register short *to, *from;
> register count;
> {
>         register n=(count+7)/8;
>         switch(count%8){
>         case 0: do{     *to = *from++;
>         case 7:         *to = *from++;
>         case 6:         *to = *from++;
>         case 5:         *to = *from++;
>         case 4:         *to = *from++;
>         case 3:         *to = *from++;
>         case 2:         *to = *from++;
>         case 1:         *to = *from++;
>                 }while(--n>0);
>         }
> }
>
> Even if you drop the whole issue of the loop interleaving with the case
> statements in Duff's Device, you could still have a situation where you
> would have a series of things that should be done with how many of them  
> you
> do depending on what the value you're switching on and you doing all of  
> the
> preceding ones for each greater value. e.g.
>
> switch(value)
> {
>     case 0:
>         do something...
>     case 1:
>         do something else...
>     case 2:
>         do a third thing...
>     case 3:
>         do yet more...
> }
>
> If value were 0, you'd need to do everything that is done at each case
> statement, while if it were 2, you'd only need to do whatever is done  
> for 2
> and 3.
>
> I grant you that in most cases, you don't need to do that sort of thing  
> and
> that missing a break is an error, but there are definitely cases where  
> being
> able to have case statements fall through can be quite handy. If it  
> wouldn't
> likely break compatability with C/C++, I'd suggest requiring a continue  
> if
> you wanted to fall through (since that wouldn't require a new keyword),  
> but
> I think that that would break compatibility in cases where the switch is  
> in
> a loop, so that's probably a no-go, and I very much doubt that Walter  
> would
> want to add the keyword fallthrough or something similar.
>
> It is an issue, but it's a well-known one, and I don't think that  
> requiring
> a break is worth the loss of power. If we push for a change, it should
> probably be in requiring a keyword to indicate that you meant to fall
> through. That would give you the safety without losing the power.
>
> - Jonathan M Davis

continue is a valid keyword inside a switch statement, so no, you can't  
use it.