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
