Chad J wrote:
Don wrote:
I think you've just created the strongest argument AGAINST this feature:
that it makes it too hard for machine-generated code. Forget the !:
hack. No chance.
If that's the strongest argument, then this is cake. I'll go through
Phobos and insert goto case's by hand if that's what needs to happen.
Most of the fallthrough I saw was stuff like this:
case '1': case '2': case '3':
case '4': case '5': case '6':
case '7': case '8': case '9':
...etc...
break;
You didn't read my post. That is NOT bug-prone. I don't think anyone
EVER makes bugs in that form.
It's actually got very little in common with a true fall-through. Real
fallthrough involves a 'goto' by stealth: the case introduces an entry
point in the middle of a code block.
BTW, it's _really_ difficult to get an unsolicited patch into DMD. It's
happened about twice ever.
I feel this matters enough that I will roll the dice anyways.
Fair enough.
The argument for it comes down to this: "fallthrough is very rare and
therefore, most uses of fallthrough are bugs".
Not as I remember.
"inline assembly is very rare and therefore, most uses of inline
assembly are bugs."
Such reasoning wouldn't get inline asm removed either. Fallthrough is
not bad because it is rare. I think that's only mentioned because the
rarity makes it easier to let go of fallthrough altogether.
Not at all. Requiring changes to existing code is a very big negative to
any proposal. If the number of changes required is small,
If many modifications to
(say) Phobos are required, then the argument for this feature is false.
From a comment someone made previously, there were about three instances
of it in Phobos. If you found you needed to make many changes than that,
I'll switch sides to Walter's camp.
"needed". Heck no. "wanted" would be more appropriate. I could have
minimized changes much more, but that costs a little in terms of the
language being nice in the long term.
There are way more than three fallthroughs in Phobos2. Most of it is
empty cases. Axing fallthrough also axes empty cases, unless you
explicitly say otherwise (and I didn't). Empty cases can be easily
rewritten into equivalent code that is also clean and pleasing.
I also minded the "default: assert(0);" pattern, quite common, which may
or may not be fallthrough depending upon how smart the compiler wants to
be. If the compiler wants to be dumb, then this becomes "default:
assert(0); break;" or similar. I was being conservative and letting it
be dumb. At least in dmd's case it's easy to recognize "assert(0);" as
unconditional branching, so it need not be dumb.
But I think you've just gone about
this wrong way.
Perhaps. I'll find out for myself.
I doubt it.
Also, I'll say it again in a slightly different way: I'd be fine with
adding no new syntax and making a special case for empty case
statements. Really I would.
Although, the "auto-generated code" argument would now
need to be addressed.
Is the auto-generated code thing really important enough to /need/ to
address it? I know I mentioned it, but I also called it "a minor point".
Man, I add a small nicety and it becomes some kind of uber awesome
argument against the much more important issue. Sorry, I don't quite
follow the logic.
You've missed the point. Andrei made a proposal for eliminating
accidental fallthrough bugs. It didn't involve any new syntax, and
changed very little existing code. Anything which violates either of
those things has very little chance of acceptance. You've done a patch
which completely ignores his proposal, and which violates both.
The comment about the auto-generated code raises an aspect which hadn't
been considered in the original proposal.
