Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.lang.c Subject: Re: Taming The Switch-Statement Date: Mon, 12 Oct 2026 22:20:30 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <11ajmfe$mfc$1@reader2.panix.com> References: <119qf6l$2rmg3$1@dont-email.me> <11ainqf$3kkvd$1@dont-email.me> <11aj73v$c2u$1@reader2.panix.com> <11ajcv8$3u33s$1@dont-email.me> Injection-Date: Mon, 12 Oct 2026 22:20:30 -0000 (UTC) Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="23020"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.lang.c:403067 In article <11ajcv8$3u33s$1@dont-email.me>, bart wrote: >On 12/10/2026 18:58, Dan Cross wrote: >> In article <11ainqf$3kkvd$1@dont-email.me>, bart wrote: > >>> This is valid C still, but it doesn't have the same behaviour. >> >> Yes. I guess I fail to see the point of these, as what you are >> trying to show seems obvious to me, and I strongly suspect it is >> obvious to others, as well. >> >> Are you suggesting that people are unaware of how `break` >> interacts with `switch` inside of a loop? I don't think that is >> true; I think people are well aware, but know how to work around >> it and don't see it as a huge impediment; more of a mild >> inconvenience. >> >> Or are you suggesting that they are trying to defend the design >> of the language in this regard? > >That's what it seems like: obstinately trying to pretend it is not a >flaw, that it makes perfect sense, then you never want to do any of the >stuff where it causes problems anyway etc. I think that may be your interpretation of what others are saying, but that is not necessarily what they _are_ saying. >There are several issues discussed regarding switch: > >* That its structure is totally chaotic (there /is/ no structure) I think Keith said exactly that; it mixes structure and no structure. >* That 'break' is needed to escape from the middle of that statement to > the end I think the discussion is mostly you saying that this is terrible, and others shrugging with their workarounds. >* That that 'break' happens also to clash, needlessly, with loop-break Yeah, I also think that's annoying. >* And also with 'case' only doing one label at a time, instead of > being able to do, for example: 'case a, b, c:' or 'case x...y', > although some of this is taken care of via extensions. That's also kind of irritating. >There's quite a lot that could have been done much better! I mean, yes. But as I said before, C is the language that it is; I will acknowledge that it could have been better, but here we are. Aside from that acknowledgement, what more is there to actually do about it at this point? >> I similarly don't think that is >> true; I have certainly been annoyed by this, and I suspect >> others have as well. But again, people know how to work around >> it. > >Yes, various workarounds are needed, such as the gotos in your examples. >But if we're going to use 'goto', then why bother with 'break' at all? > >Presumably it is to make life easier. I don't know. I wasn't in the room when it was invented; its immediate predecessor, BCPL, had no way to mark the end of a `case` in a `switchon` at all (BCPL grew `ENDCASE` later), though did have `valof` and `resultis` for obtaining the values of _blocks_. So, one could write something like: let howmany = valof switchon n into $( case 0: resultis "zero" case 1: resultis "one" case 2: resultis "two" default resultis "many" $) And so on; something one cannot do in C (but can in Rust). Why did C bother with `break;` to end a `case` and not something unique, like `ENDCASE` in later versions of BCPL? I'm speculating, but I suspect it was because they wanted to minimize the _need_ for `goto`; that unlike in BCPL blocks could not return values; that `break` already existed to break out of a loop and the control flow is not dissimilar conceptually; and perhaps more importantly they were building a compiler intended to run on a very, very small machine, shared by others, and ran out of space to build something more elaborate. By the time they had a bigger computer that could compile a better language, the construct and its consequences were well understood and there was a body of code that would have to change, and they did not feel it was worth it. At least, I imagine it was something like that. >> C is not anyone's mother; I doubt anyone who is not a kook feels >> like they need to rise to the defense of its honor when it is >> criticized. > >Defending every shortcoming or quirk to the death seems common here. And >there will always be people to whom they are an invaluable feature (see >SL's recent post). I don't think that anyone is doing that. I suspect it is the opposite: others wonder why you latch onto every quirk or shortcoming as evidence for your ultimately subjective opinion that C is a bad language. It is clear that you do not like C; you are not exactly hiding it. But there is no C language politburo; no one will denounce you for dreaming different dreams about the poor structure of `switch`, and no one is going to challenge you to a duel over your criticism of C. But it is also clear that much of your dislike is opinion, based on things that most others here just don't care about; the pecularities of the `switch` statement are a good example. I occasionally find it irritating, but 99% of the time I just don't care; one learns to write `break` and one moves on with one's life. Life is too short as it is to get worked up over the `break` statement. Others also point out that your criticism is often rooted in misconceptions or misunderstandings of the language, and that is fair: if you say something that is technically wrong about C as evidence in support of your opinion about it, then you _should_ expect pushback. That's not anyone picking on you, it's them holding you to a standard. >> What I think some people are sort of mystified by is this idea >> that this one thing is such a deal-breaker as to render the >> language unuseable. > >In my case I would find it unusable for major projects if I had to code >manually. I'm just to spoilt for one, but always I'm a terrible typist >and C needs a LOT of fiddly typing. Ok. >>> Maybe, some compilers with certain options may point out something about >>> fall-through, so you're aware something's amiss, but it doesn't get >>> around the problem: you can't simply swap if-else chains with switch >>> even when the latter is a better fit. >>> >>> This is a definite flaw in the language. >> >> It _can be_ an _annoyance_ in the language, sure. Is it a, >> "definite flaw"? That is subjective. You clearly feel that it >> is. I couldn't say whether anyone else feels that way; I think >> it's too minor to matter for most programmers. > >It's minor until it bites - see the example below. > >[snip] >This is my first example expressed in C (note those first three args are >passed by reference): > > while (pmtype = nextcmdparam(¶mno, &name, &value, "m") { > switch (pmtype) > case pm_option: ...; break; > case pm_sourcefile: > if (passlevel == run_pass || passlevel == runpcl_pass) { > break; > >Except I can't use break like that. So I have to find a workaround. > >This is also 30% more tokens than my original, and that's before I fix >this problem. The obvious syntax error aside, I'll wager that, to most C programmers, this is still minor. I won't belabor the workarounds as those are both well-known and have already been discussed several times in this thread, alone. The only part that bears mentioning here is that 99% of C programmers know perfectly well how to deal with this and, frankly, just don't find it that much of an imposition. I think the impedence mismatch with what you're saying is that, because it is so minor to so many people, it seems mystifying that you think it's such a big deal. >So I'm sure C is perfectly usable, what we can't quantity easily is how >much extra effort is needed to get things done compared to a more >amenable syntax. That may be true. But I suspect that if you took a survey of, say, 1000 C programmers, this would be unlikely to enter the top 10 complaints of more than a handful of them. - Dan C.