Switch-case made less buggy, now with PATCH!

[Don]

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.