Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C idioms (Was: >< swap operator) Date: Wed, 10 Oct 2018 16:31:56 -0700 Organization: None to speak of Lines: 53 Message-ID: References: <36d546c5-b471-45fc-b87a-8ebebdc0c0b7@googlegroups.com> <0kovD.236192$RN2.22510@fx40.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="714f42ca66b42b5b4f6239780ef2faa7"; logging-data="16131"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QaFN3BHoKsXRNXTUW4MZp" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Lae0f1s4boLPXXQ7pKJJCX6kqRA= sha1:T+f6fa2yQxc2YCJJyHneKlnfhyY= Xref: csiph.com comp.lang.c:136600 Bart writes: > On 10/10/2018 23:16, David Brown wrote: >> It would have been far better if the language had allowed: >> >>     case EDGE_1, EDGE_2, EDGE_3, EDGE_4 : >> >> Then there would be no need for the break, and you could have a >> "fallthrough" for the /very/ occasional situation where it is needed for >> something other than multiple cases that should be handled identically. >> >> Yes, I know this syntax would clash with the comma operator > > I don't think a comma operator is allowed here anyway. You're right. The syntax is: case constant-expression : statement where the definition of constant-expression (which I should have checked earlier) is: constant expression : conditional-expression That means it can't have a comma or assignment operator at the top level. On top of that restriction: Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within a subexpression that is not evaluated. Each constant expression shall evaluate to a constant that is in the range of representable values for its type. So an extension to permit a comma-separated list of constant-expressions wouldn't break anything (such a list is currently a syntax error). Still, I don't think such a change is worthwhile. Writing case EDGE_1: case EDGE_2: case EDGE_3: case EDGE_4: isn't *that* bad, and allowing commas would cause confusion with the comma operator for some readers (though of course it would be unambiguous as far as the compiler is concerned). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"