Re: Opinions on `defer`?

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.