Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: Opinions on `defer`? Date: Thu, 9 Jan 2025 22:40:24 +0200 Organization: A noiseless patient Spider Lines: 76 Message-ID: <20250109224024.00004a6b@yahoo.com> References: <87y0znpik1.fsf@gmail.com> <86sept85nz.fsf@linuxsc.com> <20250109105742.846@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Thu, 09 Jan 2025 21:40:26 +0100 (CET) Injection-Info: dont-email.me; posting-host="33430a66c04c13a3455f41d51e660447"; logging-data="3707078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Zf2jYpPLa21C94yhM1y9LQV0GBsrQoS4=" Cancel-Lock: sha1:JxSna1lsGa87yoGJ/AxbxPq5m1s= X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32) Bytes: 4239 On Thu, 9 Jan 2025 21:31:35 +0100 David Brown wrote: > On 09/01/2025 20:40, Kaz Kylheku wrote: > > On 2025-01-09, David Brown wrote: > >> On 08/01/2025 20:30, Tim Rentsch wrote: > >>> Alexis writes: > >>> > >>>> Hi all, > >>>> > >>>> "Modern C" author Jens Gustedt has been posting on his blog > >>>> about a proposed `defer` feature (as provided by e.g. Zig and > >>>> Go), the most recent being: > >>>> > >>>> https://gustedt.wordpress.com/2025/01/06/simple-defer-ready-to-use/ > >>>> > >>>> What do people here think about having such a feature in C? > >>> > >>> The issue being addressed is one well worth addressing. > >>> > >>> The proposed solution ('defer') is awful. If this feature is > >>> being considered for the C standard it should be rejected > >>> out of hand. > >> > >> Jens Gustedt is not just some random C programmer - or even just > >> some random C book author. He is an active member of the C > >> standards committee, AFAIUI. > >> > >> You might not agree with his suggested feature, and perhaps the > >> rest of the C standards committee will reject it - that's why > >> there is a committee, so that different ideas and suggestions can > >> be discussed and considered from different viewpoints. > >> > >> But his suggestion should /not/ be rejected out of hand. The guy > >> has the qualifications, and done the work, to have the right to be > >> given > > > > He has written a few macros relying on GCC features, where the real > > work has been done. > > > > That underlying GCC features is what should be standardized, if > > anything, and not the proposed defer syntax: > > > > - nested functions which have access to the parent lexicals > > - the cleanup feature > > - the __COUNTER__ preprocessor feature > > > > All of these are beyond proof-of-concept, but used in production. > > It is years old and mature. > > > > Yes, standardising these would be a good thing for C IMHO. (I seem > to recall __COUNTER__ being standardised, but I'm not sure on that.) > I believe Jens Gustedt has also proposed a form of lambdas for C - > that would work as an alternative to gcc's nested functions. > > However such local functions end up if and when they get > standardised, I think it is not unreasonable if there are > restrictions that block any usage that requires passing around data > in addition to the function. That is to say, you should not be able > to pass on a pointer to a local function that has captures - anything > that needs a gcc nested function "trampoline" or a C++ lambda style > function object should not be allowed. That would still leave full > flexibility for local use of local functions - I'd rather not open this particular can of worms (or is it Pandora box?). The only good local function is the one that don't exist > such as used here for > the "defer" macros - as well as supporting convenient local functions > for things like qsort comparison functions. > qsort is helpless regardless. Stick a fork in it.