Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Taming The Switch-Statement Date: Tue, 13 Oct 2026 16:45:04 -0700 Organization: A noiseless patient Spider Lines: 125 Message-ID: <86mrshgo73.fsf@linuxsc.com> References: <119qf6l$2rmg3$1@dont-email.me> <11ac783$1bkuo$1@kst.eternal-september.org> <11ad5eq$1l8hg$1@dont-email.me> <11ad9fg$cjm0$4@dont-email.me> <11addhr$1oakb$1@dont-email.me> <11aduuk$cjlv$1@dont-email.me> <20261010220212.000063fd@yahoo.com> <11ae56o$cjlv$4@dont-email.me> <20261010230355.00005189@yahoo.com> <864iesjx6e.fsf@linuxsc.com> <11afvqt$2kloc$1@dont-email.me> <11ag37o$2ln0a$1@dont-email.me> <11agbsh$2pbk7$1@dont-email.me> <11aggaq$2qqh9$1@dont-email.me> <11agils$2s3tg$1@dont-email.me> <11agv1t$30q22$2@kst.eternal-september.org> <20261012220256.00003d07@yahoo.com> <11ajb95$3t8jj$1@dont-email.me> <20261012223144.00000f95@yahoo.com> <86zewhhdep.fsf@linuxsc.com> <20261013225449.00005562@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 13 Oct 2026 23:45:05 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1020184"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VNvnu2u8ceztLs7LXlOjfqnyipBJ0b2E="; posting-host="065d2eee2cd7241f5f1e4f229d8fc207" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:EcCvZkkYZTrsZCSZKwd7ak85h6I= sha1:9BRuXfz6cn/eHHe4sanOs+qgJ+0= sha256:o5RF1OnO9jxeYDfLP5Y5KwpuLGNLE84Pvug50kPgduA= sha1:Iht4rCZgclcH0sWGTcEuIzp9Tzw= sha256:AqrqYkWSQWB5f/y2x2Ir1fTlPZpE7l/tENsXCEGHMGU= Xref: csiph.com comp.lang.c:403133 Michael S writes: > On Tue, 13 Oct 2026 07:40:30 -0700 > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Mon, 12 Oct 2026 21:09:25 +0200 >>> David Brown wrote: >>> >>>> On 12/10/2026 21:02, Michael S wrote: >>>> >>>>> On Sun, 11 Oct 2026 14:28:29 -0700 >>>>> Keith Thompson wrote: >>>>> >>>>>> bart writes: >>>>>> [...] >>>>>> >>>>>>> 'break' to quit a loop early is part of the language, so why >>>>>>> shouldn't someone make use it? >>>>>> >>>>>> Agreed. (There are coding styles that require loops to exit only >>>>>> at the bottom, but that's not what we're talking about.) >>>>>> >>>>>>> It just its use can be interfered with when 'switch' is >>>>>>> involved. >>>>>> >>>>>> Yes. Everyone here knows that, and knew it before you started >>>>>> talking about it. >>>>>> >>>>>> Michael S wrote above that "The cases where I want to break out >>>>>> of the loop from the switch in the body of the loop are very >>>>>> common." Tim Rentsch questioned the "very common" part of that, >>>>>> and asked for an example. You jumped in and asserted that an >>>>>> example isn't necessary, because you misunderstood what was >>>>>> being said. >>>>> >>>>> I didn't read the whole subthread, but from what I read it seems >>>>> that the only reader that misunderstood my statement was David >>>>> Brown. The rest, including bart, understood just fine. >>>> >>>> If I have misunderstood, I would love to be corrected. In a number >>>> of my posts I said I was not sure what you were talking about, and >>>> would need more explanation. >>> >>> I thought that my comment is hard to misunderstand, but you proved >>> me wrong. So I'd try to elaborate: >>> >>> switch() nested within loop is very common in my practice and I >>> suppose in practice of everybody else. >>> >>> In my practice, but obviously not in practice of Tim Rentsch, it >>> is sufficiently common to want to transfer control from point within >>> such nested switch to point immediately following the containing >>> loop. >> >> Let me clarify my earlier comment. I'm not surprised that people >> routinely use switch() inside of loops. What did surprise me is the >> statement that wanting to break out of the loop from inside the >> switch() is "very common". Not happens occasionally; not happens >> commonly or even just sufficiently commonly; not happens routinely; >> but "very common". I am wondering now how common it actually is, >> for switch() in general and for switch() inside of a loop. Is it >> one in a hundred? One in ten? One in two? More than that? > > Of course, I never gathered exact statistics. > My guts feeling is that among switches nested within loop it could be as > high as one out of five. Not one out of five case labels, but one out of > five switch statements. Gut feelings are fine. Thank you. >> I asked for an example because I am curious about what the proximate >> cause of such commonality might be. Is it a general style matter? >> Is it that you are used to certain patterns of local control flow? > > My own use cases are mostly related to processing of incoming network > messages that are distinguished by opcode at the beginning of the > message. Okay. Does this mean the loop exit indicates the end of the last packet so the last packet can be processed (and start another one presumably)? Or am I misunderstanding you? > But not just that. Generally, I like small functions that return > specialized enum as result code. When such functions used within > loop, it often leads to pattern in question. I expect this pattern leads to using switch() more often. So that could account for part of it. >> Is it that some use cases are more common in the kinds of programs >> you deal with? It would be good to get some data here, even just >> ad hoc data. > > Sorry, right now I have no time for doing such analysis. It is not > trivial exactly because 'C' has no such feature. So I don't know how > to automate a search within codebases. An approximate measure is how often 'goto' is used inside a switch() body. That would be interesting to know in any case. Whether it would be easy to do that heuristically probably depends on what code base is being processed. >> In my own experience, wanting to escape multiple levels (including >> the case of provoking a loop exit from inside a switch()) doesn't >> happen often enough to merit considering a language change. But I >> would like to know more about the experiences of other people. >> >> I'm reminded of a quote from (if memory serves) Tony Hoare, about >> language design. Paraphrasing: A programming language should not >> reflect the union of all the features proposed by its designers; >> rather it should reflect the union of the designers' prejudices >> about what features should NOT be put into the language. > > In this particular case Ritchie did not have to innovate in order to > create this feature. Quite opposite, as others (Keith ?) mentioned, > he had to innovate in order to merge distinct break-loop and > break-switch features of ancestor language into unified break. Sorry, it seems my comment led you astray. I was talking about something else. In any case Ritchie was operating under very different circumstances, including in particular more severe memory constraints. At the time adding another keyword to the language may have seemed like an extravagance.