Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Kaz Kylheku <643-408-1753@kylheku.com> Newsgroups: comp.lang.c Subject: Re: Loops (was Re: do { quit; } else { }) Date: Mon, 21 Apr 2025 22:16:54 -0000 (UTC) Organization: A noiseless patient Spider Lines: 86 Message-ID: <20250421145818.767@kylheku.com> References: <20250419092849.652@kylheku.com> Injection-Date: Tue, 22 Apr 2025 00:16:55 +0200 (CEST) Injection-Info: dont-email.me; posting-host="537fe17c48f9c04d98dc75d8e3fbb7fc"; logging-data="3285617"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Yxgu7qPEUj7BYPD7rsVqpYISjNHfXMB4=" User-Agent: slrn/pre1.0.4-9 (Linux) Cancel-Lock: sha1:Yj1dQ3suxHgEXUMvIPirA/CPkuE= On 2025-04-21, bart wrote: > I don't now think think there is any argument that will make any > difference. People here genuinely think that writing: > > for (ch = 0; ch <= 255; ++ch) > > is far superior to this 'primitive' version: > > do ch = 0, 255 Obviously, the former is more primitive, because the second can be made out of the first with a preprocessor, whereas the converse is not true. If A can be made out of B, but B not out of A, B is more primitive. The former is undeniably more verbose for the uses provided by the second. It is also much more flexible. Thanks to the macro preprocessor, it can almost express the second form, just with more punctuation: for_range (ch, 0, 255) If a built-in "do" range loop existed in C, it would likely have the parentheses. > No amount of discussion or arguments will make them change their minds. Mostly, you are projecting onto people opinions they don't actually have. > (BTW I had to fix two typos in the C, as in the first version I > initially used 'ch, c and c'!) > > Apparently, the C form is superior because that construct can also be > used to conveniently express link-list traversal, and a lot more. It has superior flexibility. Flexible is not a synonym for superior; flexibility doesn't make something unequivocally superior, unless we can hold "all else equal". We can almost never do that. Here, the flexible thing is more verbose, and there are challenges implementing a simple range iteration that can go (for instance) all the way to INT_MAX, whereas the less primitive loop can get that right and completely hide it from the programmer. > Even the idea of having *two* kinds of loop, one as it works now, and > one more streamlined, was not acceptable: too much 'overloading' of the > language. You're also not a fan of unbridled language extension, based on your past opinions about, oh, C++ and whatnot. Your primary reaction to some new idea is to reject it as complex fluff that you'd rather not undertand. How brushed up are you in using C17 or C23? You've also expressed oppositions to extending C, because development of C makes it a moving target for your projects. Of course people are going to push back on the idea of making new statements, if they can be decently obtained or simulated using preprocessing. Would you support an "unless" statement being added to C, given that we can just: #define unless(x) if(!(x)) Or, unless which does not take else: #define unless(x) if (x) { } else Adding a new statement to C is a big deal, compared to someone adding a macro to their code. Literally the first question about any proposal for a new language feature is going to be: can obtain that, or substantially obtain it using existing features -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca