Is there ANY chance we can fix the bitwise operator precedence rules?
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Mon Jun 21 16:45:27 PDT 2010
On 06/21/2010 06:01 PM, Jonathan M Davis wrote:
> Andrei Alexandrescu wrote:
>>
>> After Sean's example, goto case XXX is my fave for fallthrough. I don't
>> like unlabeled "goto case" to mean fall through, it's one of those "need
>> to look in the manual" features. goto case XXX is generalized fall
>> through.
>>
>> Andrei
>
> Well, it definitely works, but then you run into the issue of whether you
> used the right XXX. That's the kind of place that rearranging code is likely
> to run into bugs whereas "goto case" by itself or "continue switch" would
> just fall through.
Here's where statistics come forward:
- code that uses fall through: rare
- code that uses fall through and needs to be rearranged: rare * rare
- code that uses fall through, needs to be rearranged, and the
rearranger doesn't even look at the statement IMMEDIATELY PRECEDING the
moved case label: rare * rare * rare
We're looking at three orders of magnitude here. I think it's reasonable
to not dedicate too much language design to this case.
> It also makes it less obvious when you have errors with
> "goto case XXX" being intended to jump somewhere other than the next case.
Example that may actually refer to real-world code?
Even Duff's device will have a sensible definition, albeit more verbose
(which is GOOD): each label action will end with "goto case that_label-1".
> If you're using a statement that is explicitly for falling through, then
> it's clearly differentiated from a statement where you're jumping to a case
> other than the next one.
I have zero empathy with that distinction. On the contrary, I think code
should be written in terms of going from one label handler to another,
instead of falling into whatever comes next.
> I can't say that I'm terribly found of "goto case"
> by itself, but at least it would be less likely to cause bugs when
> rearranging code and more clearly indicates the intention to fall through.
Zero.Empathy.
> It still isn't as good a statement which can only be used for fallthrough
> (and therefore couldn't be a "goto case" where you were supposed to put a
> target but didn't), but I see no advantage in using "goto case XXX" for
> fallthrough instead of "goto case".
I see no disadvantage, and on the contrary, many disadvantages for the
cryptic "goto case". (What if it means go again to the current case?)
The problem is, if Walter sees us bickering too much, he'll use that as
pretext to veto out any improvement.
> "goto case" does seem a bit silly, but I think that it's clearer
No clarity for me.
> and less
> error prone for anyone who understands "goto case."
I don't see that.
> The only issue is the
> fact that it would be odd for someone who didn't know that you could do
> that, but there's plenty of that to go around already, and it's not like it
> would be hard to remember when you see it if you've already looked it up.
Yeah, but it's not like we want to add such cases without necessity.
Andrei
More information about the Digitalmars-d
mailing list