Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
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>
	<vlohbs$3bs33$3@dont-email.me>
	<20250109105742.846@kylheku.com>
	<vlpbn7$3h5u8$1@dont-email.me>
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 <david.brown@hesbynett.no> wrote:

> On 09/01/2025 20:40, Kaz Kylheku wrote:
> > On 2025-01-09, David Brown <david.brown@hesbynett.no> wrote:  
> >> On 08/01/2025 20:30, Tim Rentsch wrote:  
> >>> Alexis <flexibeast@gmail.com> 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.