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

Jonathan M Davis jmdavisProg at gmail.com
Fri Jun 18 20:17:09 PDT 2010


Andrei Alexandrescu wrote:

> Jonathan M Davis wrote:
>> bearophile wrote:
>> 
>>> 2) switch cases that don't end with goto or break:
>>>
>>> void main() {
>>>     int x, y;
>>>     switch (x) {
>>>         case 0: y++;
>>>         default: y--;
>>>     }
>>> }
>> 
>> I, for one, _want_ case statements to be able to fall through. It would
>> be horribly painful in many cases if they couldn't. Now, requiring a
>> separate statement like fallthrough or somesuch instead of break might
>> not be a bad idea, but requiring that each case end with a break would
>> seriously restrict the usefulness of switch statements.
> 
> I agree. But the basic idea is to do extra work if you're doing
> something unusual, and falling through is unusual.

Certainly a good principle and one that D holds to for the most part - 
certainly far better than many other languages.

> 
> A while ago it was proposed to require each case block to end with a
> control flow transfer statement (break, continue, return, throw, or goto
> case XXX). The latter allows fall through in the rare cases that were
> needed, requiring just a bit of extra umph from the programmer. Perfect
> solution.
> 
> My recollection of the matter is that Walter rejected the proposal
> claiming that he uses fall through all the time. Don ran some
> measurements over Walter's own code and proved him copiously wrong.
> Walter had no retort to that argument, so he veered into a critique of
> the goto case XXX solution saying it's unmaintainable: when you moving
> code around you want to keep on falling through but with goto you'd need
> to update the goto target. However, it can be argued that logically you
> want to continue processing at some specific logical point, not to
> blindly fall through to whatever the heck code happens to be there.
> 
> So ultimately the whole thing fizzled. Apparently the current situation
> is optimal for programmers who use fall through "all the time", who move
> code that is fallen into all the time, have weird expectations of code
> after the move, and never check that jumps are made to the right labels.

Requiring goto for fallthrough certainly strikes me as less maintainable (if 
nothing else because you have to say where you're going - if you could just 
indicate fallthrough without having to indicate a jump target, it wouldn't 
really be a problem) but not necessarily unacceptabley so. I use fallthrough 
often enough that I definitely want to have it, but I'm not rearranging my 
switch statements so often that having to fix the gotos would be a huge 
source of errors (though being able to just indicate fallthrough - maybe 
with just goto with no target, though that could be a problem with the 
grammar - wouldn't be as big a problem).

> 
> As an aside, I think it's an interesting psychological phenomenon: I
> think we often have skewed beliefs about the frequency of our patterns.
> It often happens that switchers to a new language believe they won't be
> able to make it through the day without feature X (bitfields, anyone?
> :o)) yet practical experience soon shows otherwise.
> 
> 
> Andrei

It definitely can be interesting. Of course, some of the problem is that 
there are features that you use semi-often but are easily replaceable while 
there are other features that you don't necessarily use all that often but 
would be awful not to have - and knowing what you need ahead of time is 
often hard. I don't use function pointers all that often, but it can be 
highly frustrating to program in Java when I could really use a function 
pointer and don't have one. Of course, that opens up the issue of how 
useable the feature is as implemented vs how useful it would be if it were 
useable. I don't use the algorithm library much in C++ because declaring 
functions or functors to pass to it is just too much of a pain. It's too 
hard to use for it to be worth it usually. However, D makes that sort of 
thing much easier with lambdas and inner functions and the like, so I use 
std.algorithm fairly heavily.

In any case, the whole issue of what we really use and  what we really need, 
and how that compares to what we think that we really use and need could 
probably cover quite a few papers if you really started looking into it.

Regardless, whether goto is required for fallthrough in a switch statement 
or not, I definitely want fallthrough.

- Jonathan M Davis


More information about the Digitalmars-d mailing list