dmd 1.046 and 2.031 releases

[Andrei Alexandrescu]

Chad J wrote:
> Andrei Alexandrescu wrote:
>> Chad J wrote:
>>> These bugs always take me no less than 2 hours to find, unless I am
>>> specifically looking for fall-through bugs.
>> I agree. Probably a good option would be to keep on requiring break, but
>> also requiring the user to explicitly specify they want fallthrough in
>> the rare case when they do want it. I'd love to use "continue" for that
>> but it's already "occupied" by cases like while (...) switch (...).
>> Requiring !break or ~break would work but is a bit too cute. Adding a
>> new keyword or a whole new switch statement is too much aggravation. I
>> guess we'll have to live with it...
>>
>>
>> Andrei
> 
> Don't marginalize something that's important!
> 
> The syntax is arbitrary.  Just pick something that works.

I've posted here and also sent private message to Walter asking him what 
he thinks of requiring each case to end with a control flow statement.

> Also, IIRC, the main argument in favor of fallthrough behavior was
> compatibility with C code.  Now that we have "final switch", we can,
> with reasonable certainty, assume that no C coder has written "final
> switch(...) ...".  Thus we are allowed to choose a syntax that's
> different without breaking anything.  And for those few people that want
> to write Duff's device, they can just use the old style switch-case.

That's not the restriction we're having. The C-compatibility restriction 
is to not have code that compiles in both C and D and has different 
semantics in the two languages.

So requiring all case-labeled sections in a switch statement to end with 
a control flow statement would leave some code that compiles in C but 
not in D. That is acceptable.

> <rambling and syntax>
> I'm personally a bit biased to the haXe switch-case statements that I've
> been using for the past few months.  In haXe you don't even have to
> write break; at the end, it will always exit the statement at the end of
> a case-block.  It also has that behavior added in final switch where
> switching on an enum requires you to be exhaustive about your handling
> of the possibilities.  It has worked well.  If it isn't powerful enough,
> there's always "goto label;" where label is either some external label
> or the name of one of the cases.  I think I've seen that in C#.  That
> also worked well.
> 
> So something like this:
> 
> final switch( foo )
> {
> 	case 0: goto 1; // emulate the fallthrough
> 	case 1: writefln("Got a zero or a one.");
> 	case 2: writefln("This isn't supposed to happen.");
> }
> 
> I wouldn't complain if it was done some other way though.  Just killing
> the fallthrough bugs would make me so much happier.
> </rambling and syntax>

There is a goto case statement in D already. The only change we need to 
effect is to require it for fall-through code.


Andrei