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