C2y/C3a Proposal - Improved attribute((cleanup(...))) through defer
https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Improved%20__attribute__((cleanup))%20Through%20defer.html
You must log in to comment.
in reply to @ThePhD's post:
RE "Comment" - I managed to get very confused by example 14 and I think it was due to the bracing - the absence of braces got me to "...wait that's 17 not 35" due to unwinding things wrong in my head. Not that I would make any guarantees that the same mistake couldn't happen to me if braces were mandated, possibly I just needed to read closer.
defer without braces is easy to write, but when nested and around other stuff it may be confusing. The good news is that if you leave off the braces, you can only put a single expression in there. So trying to put defer if (...) ... or some other nonsense is just a straight up error.
Yeah - C is the language of not-always-needing-the-braces so it's not like I shouldn't expect this kind of thing.
Big fan of the flow control suggestions re goto and return, big hater of longjump but that's not exactly defer's fault -_-)
longjmp will forever be just out of our clutches, dancing in the binary, unlimited and free from our schemes and machinations,
EXTREMELY big fan of not adding ctor/dtor to structs - frankly even in C++ I'm kind of annoyed they're in structs, I'd prefer struct had C semantics and class had C++ semantics for a very pure split between the two.
If we could solve the name mangling problem appropriately, I'd consider adding member functions to C. And constructors, etc.; but all of this has to be controllable by the C user, not by the implementation.
The comments section of cohost is probably not the place to write My Whole Opinion out but mainly: The primary thing I'd want to do in a dtor is call free/fclose/etc - which is fine in C++ where the members can be private so I control the necessary invariants, but in C it'd be a disaster I think. Probably a good design around it could be possible but I would not trust myself to make it.
interesting! never actually read a language proposal before but this was structured to be super readable and understandable to me c:
my only real question with is it that i don't entirely understand how control flow (goto, return) works if it skips over a defer block, i assume it doesn't execute the defer, but at some points you mention that goto-ing over a defer is "banned"? so i'm not sure if it's supposed to not execute the defer or just not compile if an attempt to goto over it is made, or is it just undefined?
You are not allowed to skip over a defer block with goto. You may return early and not reach a defer block.
i see, is that just goto? like for instance can i defer within a conditional (e.g. if ( thing ) { defer { /* stuff */ } ))? or is the assumption that defers are always static (i.e. if a defer is written in a function, it should always be executed)
No, if thing does not resolve to true, then the block isn't entered, and the defer is never run. It's not scoped to the whole function, it's scoped to the innermost block scope present (usually, the innermost set of { } unless somebody's using an if without braces or something).