Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Opinions on `defer`?
Date: Wed, 8 Jan 2025 17:30:53 -0300
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <vlmn9u$2uoj1$1@dont-email.me>
References: <87y0znpik1.fsf@gmail.com> <86sept85nz.fsf@linuxsc.com>
 <vlmn0a$2trcl$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 08 Jan 2025 21:30:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2a2ffc332fcdbdc87a49d350ecc73b20";
	logging-data="3105377"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/oyxl9MY/nzYnkgfkXG/ndT02esDXEMd8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6SKP1Dz4qV+oRYeZr1bOcgdfsK0=
Content-Language: en-US
In-Reply-To: <vlmn0a$2trcl$1@dont-email.me>
Bytes: 2872

On 08/01/2025 17:25, Thiago Adams wrote:
> On 08/01/2025 16: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.
>>
> 
> What is the issue in your opinion?
> 
>> The proposed solution ('defer') is awful.  If this feature is
>> being considered for the C standard it should be rejected
>> out of hand.
> 
> Why?
> 
> I will tell what is the issue it solves in my opinion.
> If you don't have static analysis to guide you on where to free 
> resources, defer helps prevent human error by ensuring resources are 
> released properly. With defer, you only need to specify the cleanup in 
> one place, reducing the chances of forgetting it elsewhere. This makes 
> the code easier to maintain.
> 
> However, I think this problem is better addressed with static analysis, 
> which provides stronger safety guarantees.(This is what I have done in 
> Cake, with static analysis)
> 
> If there's a better solution, is defer unnecessary?
> 
> I think defer still useful to write less code, to add the same 
> information in just one place.
> 

Forgot to say...

I think defer can complement static analysis. Even if static analysis 
improves, the two features are not in conflict; they can work together. 
The evolution of static analysis won't compete with defer; otherwise, I 
would simply say, 'Hold off', because a better solution would be coming 
in the future.