Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: A defer mechanism for C
Date: Sun, 27 Dec 2020 05:19:13 -0800
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <86lfdjwfn2.fsf@linuxsc.com>
References: <3a965b75-7eb6-4287-8e19-8969b6628d90n@googlegroups.com> <20201216021146.ca064b8caaa4a51f9de2b800@gmail.com> <87czza4l1p.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="7428659b5bf23ec7739a8c9d5f9c9404"; logging-data="12195"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5HwOs9tRj6JONv39Jq/zjOAjWe09zt7k="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:6Ushedqz/eHqwIbVprNfJ1Qcd78= sha1:SGF9nxr/n7ng/tW1HExYWcQZlbQ=
Xref: csiph.com comp.lang.c:157815
Ben Bacarisse writes:
> Anton Shepelev writes:
>
>> Thiago Adams:
>>
>>> https://gustedt.wordpress.com/2020/12/14/a-defer-
>>> mechanism-for-c/
>>
>> Is it the first consturction that, if accepted, will break
>> C's literal interpretation of control-flow statements by
>> introcuding a kind of action at a distance (and over time)?
>> All the other control-flow statements are executed
>> immediately...
>
> It's not entirely unlike atexit() and at_quick_exit(), but I agree its
> a significant departure.
I appreciate the effort that went into writing the proposal.
But the proposal itself is a disaster.