Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language: cases
Message-ID: <2928@haddock.ISC.COM>
Date: 8 Mar 88 17:16:27 GMT
References: <222965b9@ralf.home> <2403@umd5.umd.edu> <25200@cca.CCA.COM> <562@acf3.NYU.EDU>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 29

In article <562@acf3.NYU.EDU> pedersen@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@haddock.isc.com), The Walking Lint