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.