The D Programming Language: cases

[Karl Heuer]

In article <562 at acf3.NYU.EDU> pedersen at acf3.UUCP (paul pedersen) writes:
>Fallthrough may be occasionally justifiable.  [As in case Subtract doing a
>negate and then falling into case Add.]

Of course, even C-like fallthrough isn't good enough if you have THREE cases
that end up at the same point.  (Assuming the code to be executed is AC | BC |
C, not ABC | BC | C.)  Or even two cases with different initial segments (AC |
BC).  Might just as well use the same construct (goto) for all of these.  (But
I do like `goto case X` and `goto default`; one ought to be able to use the
existing label.)

>I do not think, however, that such a "general" concept as either fallthrough
>or on-the-fly constructors should be used to support the common use of
>multiple cases which execute exactly the same code.  Here some other syntax
>is needed.

I agree.

>The natural 'case a,b,c:' is defeated by C's comma operator,

That's no worse than the other comma conflicts.  If the comma operator is
still illegal in constant expressions (it was in an early Draft; I haven't
checked the latest one), this syntax could be added to C with no conflicts.
If not, then could add it anyway, and let it override the comma operator just
as `f(x,y)` does.  (If for any reason you actually need a comma operator in a
case statement, you write `case (A,B,C):`.)  If we're talking D rather than C,
we don't even have to worry about breaking existing code.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint