On Mon, Apr 26, 2021 at 5:51 PM Ville Voutilainen via Liaison
<liaison_at_[hidden]> wrote:
>
> I use some myself, the GNOME ones. I can't fathom why they bother.
> Feel free to add destructors to C and we can talk. :)

Semi-related, C is looking into doing exactly that:

http://robertseacord.com/wp/2021/03/20/defer-mechanism-or-c-the-movie/
Slides: http://robertseacord.com/wp/wp-content/uploads/2021/03/Defer-Mechanism-for-C.pdf
Paper (which may need some updates to match the above
slides/presentation):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2542.pdf

Although I believe that defer is actually a "more fundamental" version
of destructors (a "general purpose undo mechanism", as Scott Meyers
called destructors) because it's not coupled to a constructor feature
and not bound to an object's lifetime. This also means that you can
have it (transiently) refer to more things than you would if it was a
destructor, which normally requires capturing those variables and
doing other things (concerns which are covered, mostly, by lambdas).
So at least we're taxing the optimizer a tiny little bit less to get
rid of references to certain pieces of data!

This kind of more "basic" functionality was, of course, embodied in
the scope_guard (https://wg21.link/p0052) discussion, but that paper
fell prey to a lot of concerns about having potentially non-noexcept
destructors and being a std lib type, if my memory serves correctly.
(It was mostly before my time and getting that problem solved required
admitting destructors shouldn't be non-noexcept; thus, defer solves
that problem in a way the standard library can't handle without
breaking some rules.)