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

[Jonathan M Davis]

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