Path: utzoo!mnetor!uunet!husc6!bbn!rochester!udel!burdvax!sdcrdcf!ism780c!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language: switches
Message-ID: <3074@haddock.ISC.COM>
Date: 20 Mar 88 22:04:04 GMT
References: <222965b9@ralf.home> <941@micomvax.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 30

In article <941@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes:
>Case statements should just be generalised into a "shorthand" way of
>stating if...elseif...elseif...else...

I disagree.  The else-if chains already provide a perfectly good way of doing
that, and are just as concise.  There's no need to add a second syntax of
equivalent power.  In fact, the existing switch statment is more concise in
the job for which it was designed: you can write "case VALUE:" instead of
"case (long_hairy_expression == VALUE):".  If the controlling expression has
side effects, your "enhanced" switch would require an extra temporary.

Yes, in a sense switch is less powerful than an else-if chain.  Let's keep it,
for the same reasons that we retain flow constructs less powerful than goto.

The existing switch isn't perfect, of course.  I do think we should get rid of
automatic fallthrough, and allow a list of values (or a list of ranges) for
each label.  Then the case-blocks would be commutative.

>Compilers can easily generate just as "efficient" code when only constant
>expression values are involved

Oh?  Do any compilers currently optimize if-else statements in this way?

>(MSC 4.0 seems to generate worse code when you use a case statement than when
>you use an if...else if...else... sequence!).

A compiler that doesn't optimize the existing switch is unlikely to do
anything intelligent with the generalization.

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