A simple defer feature for C

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

by ingve • 5 years ago

205 232 5 years ago

open-std.org

aaaaaaaaaaab• 5 years ago

Just use C++. No need to proliferate the C language.

neatze• 5 years ago

I highly doubt you can explain why.

kaba06• 5 years ago

Not the parent commenter, but namespaces alone make the switch a no-brainer. Add on top RAII, actual abstractibility (good luck implementing std::string in C properly) make it a strictly worse language.

jcelerier5• 5 years ago

Took a few years for C to adopt function prototypes from C++, one can hope that RAII makes it in less than a century

thechao2• 5 years ago

I hope it's not mandatory. I'd much prefer static analysis to tell me of use-before-acquire errors: I have a number of hot-inner-loops where initialization nukes performance.

edflsafoiewq• 5 years ago

Can you give an example of how initialization nukes performance?

jibalt5• 5 years ago

Prototypes were in the original C standard of 1985, before first edition of The C++ Programming Language was released and long before C++ was formalized standardized.

Sindisil• 5 years ago

Oy. Your history is ... confused.

While the first draft was released in 1983, the first ratified C standard was in 1989.

The first edition of "The C Programming Language" (from which I first learned the language) was published in 1978, over a decade before the language was standardized.

You are correct that C89 added function prototypes. However, contrary to your implication, C borrowed the concept and syntax from C++.

ohCh6zos2• 5 years ago

Defer is a bad feature in Go and I'm hesitant to see it spread to other languages. It exists as a hack because error handling in Go is convoluted.

leni5362• 5 years ago

Defer is weird in Go, being tied to function scope instead of immediate block scope.

ohCh6zos2• 5 years ago

You're right, that is a better way to put it than what I said.

assbuttbuttass2• 5 years ago

Function scope allows constructs like

    for _, lock := range locks {
        lock.Lock()
        defer lock.Unlock()
    }

To acquire locks in a loop and release them at the end of a function. Otherwise the previous lock would be dropped each time the loop executes.

I've never seen the advantage to having a block structured defer: it's easy to add a new function, it's not always possible to remove a block.

bboozzoo• 5 years ago

What in your view makes defer a bad feature of Go? Maybe my bar is low, but each time I jump back to C I wish I had defer and end up abusing __attribute__((cleaup)) instead.

SV_BubbleTime• 5 years ago

error handling in Go is convoluted

Is it worse than in C that there is no concept at all? Is it better that everyone is on their own to do it their own way every time?

I’m not above making the eaiser, but to your point when I see their example of:

  double* q = malloc(something);
  defer [qp = &q]{ free(*qp); };

That doesn’t look like the C that I know.

pjmlp8• 5 years ago

The C you will get to learn is also planning to have lambdas, and they are being based on C++ design rather than Apple's blocks, so the example assumes they will also be in C2X.

halpert• 5 years ago

Being able to close an open resource when a function returns is generally useful. It has nothing to do with error handling.

kgeist4• 5 years ago

It exists as a hack because error handling in Go is convoluted.

What's the alternative, though? Sprinkle your code with try..finally's? RAII like in C++?

the_gipsy2• 5 years ago

Result types

qsort• 5 years ago

Context managers, or an Auto-Closable interface with syntactic support.

Also why is RAII bad? It's an awesome feature in C++.

w4rh4wk5• 5 years ago

RAII is fine. If it's a language feature, APIs can provide that to you so you don't have to write RAII wrappers all the time.

Otherwise a generic _bracket_ operator could be introduced, similar to Python's `with` statement. In C it might be a bit hard to parameterize, but even if it just requires you to use a void, it's still an improvement vs. not having anything at all. (Talking about language features so `__attribute__((__cleanup__))` doesn't count.)

Imagine something like this:

    FILE* handle = bracket(fopen("data.bin", "rb"), fclose) {
        fread(..., handle);
        return;
        fwrite(..., handle);
    } // <-- implicitly calling fclose(handle), always

Edit: After writing this sample I could even an optional `else` block in case `fopen` returned `NULL`.

Edit2: Of course, syntax fine-tuning would be welcome. For instance, `handle` should be restricted to the bracket's scope.

laumars• 5 years ago

It’s already exists in other languages and it exists because a function could have multiple different exit points. Even if Go had different error handling there might well be different exit points. Hence why defer isn’t a Go-specific feature.

Thaxll2• 5 years ago

Defer has nothing to do with error handling. Defer is a great feature in Go, I've never seen someone complain about it.

laserbeam4• 5 years ago

Defer CAN help with error handling, but you need other language features for that. You need well defined error types or exceptions in some way or another.

Zig has errdefer which only runs if an error occurred below the statement within that scope. It allows you to always keep cleanup locally, but you can still handle errors for your business logic somewhere else.

errdefer is cool, but I don't think C should support it. Mainly because you'd need to spec errors at a language level, and doing that today is probably impossible.

marcodiego• 5 years ago

The new defer proposal has the potential to make code easier to read, remove some uses of goto's and help to fix some resource leaks that are so common on old non-GC languages. Certainly a feature I'm rooting for.

The only other proposal I'm more interested in are the lambda approaches: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2890.pdf

rwmj4• 5 years ago

Ugh please don't do this. Just standardize the existing __attribute__((cleanup)) mechanism which is already implemented by compilers and widely used in many free software projects.

kps• 5 years ago

“this feature cannot be easily lifted into C23 as a standard attribute, because the cleanup feature clearly changes the semantics of a program and can thus not be ignored.”

nmilo4• 5 years ago

Then it doesn't need to use the existing attribute syntax, which requires that attributes can be ignored. They can make a new syntax.

rwmj4• 5 years ago

That's a very weak objection. In any case since most programs are hiding __attribute__((cleanup)) in a macro (eg. glib's g_autoptr macro or systemd's family of _cleanup_* macros) you could use another kind of annotation.

The point here is that the C working group should be standardizing existing practice and helping the existing users of C, and not striking out making bizarre new syntax choices and keywords which are completely unproven.

jibalt5• 5 years ago

So don't lift it as a standard attribute.

10000truths• 5 years ago

__attribute__((cleanup)) is ugly because for some reason, the gcc folks decided that the parameter passed to cleanup needed to be a function pointer of signature void(void**) instead of the much more sane void(void*), with no way to allow implicit casting of the parameter to a function pointer of different type, so none of the basic cleanup functions (e.g. free, fclose) work with it out of the box - you need to pollute your codebase with one wrapper for each cleanup function that you want to use.

They should have made it so that cleanup took an expression block:

    void* foo __attribute__((cleanup({ free(foo); }))) = malloc(bar);

Or at least allow a statement expression returning a compile-time known function pointer:

    void* foo __attribute__((cleanup(({ void wrapper(void** p) { free(*p); }; wrapper })))) = malloc(bar);

Sure, it still looks ugly, but at least a single generic macro would be able to clean it up and make it look better.

kaba06• 5 years ago

Oh my God, why do we put up with C at all?

rwmj4• 5 years ago

Sure - I agree! But, it exists and it's widely used already. The C working group should concentrate on standardizing existing practice and not start striking out on unproven and weird new syntaxes and keywords.

eqvinox2• 5 years ago

The "good" way to go about that would be to have a second "cleanup_value" attribute.

(Or, since the standard would be creating new names, have "cleanup" and "cleanup_ptr" instead. Assuming that this is a separate attribute namespace, which I believe it is[?])

FWIW, you do sometimes need the address of the variable. Particularly if it's some struct that is made a member of some container (e.g. linked list) temporarily - you need the original variable's address to unlink it.

nmilo4• 5 years ago

I really don't like it. The lambda stuff, especially the captures that were ripped from C++, don't fit C at all. The question about whether it should be cleaned up at end-of-scope or end-of-function is too ambiguous and debated. And if I'm understanding this correctly, this is the worst part:

This indicates that existing mechanism in compilers may have difficulties with a block model. So we only require it to be implemented for function bodies and make it implementation-defined if it is also offered for internal blocks.

How will that work?

jimjams• 5 years ago

Since variables can be scoped to blocks, and allocation scopes can be arbitrary, needing neither a function or block scope to bracket them, I don't see how that will fly either.

massinstall• 5 years ago

I agree and don’t like it either. +1

bangonkeyboard2• 5 years ago

I was, and continue to be, very disappointed that the (to me) more natural and C-like block syntax for lambdas was rejected from C11 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2030.pdf).

b3morales2• 5 years ago

In practice those signatures can get a bit tiresome to write out, but I agree, they fit much, much better with C syntax and mindset.

nmilo4• 5 years ago

I think that idea is pretty cool. I don't like the new closure pointer type, and how all functions that take function pointers need to be retrofitted to take closures as well, but I guess it's necessary. I assume closure pointers would be implemented as a double pointer, one void* to point to the captured variables in memory, and one function pointer to point to the procedure. One of the most annoying parts of C is how callback logic needs to be defined completely separately from the calling logic.

friend-monoid• 5 years ago

I’m not sure, im no compiler programmer but I prefer not requiring an allocator like malloc and copying data and reference counting. But I don’t know.

cyco130• 5 years ago

Isn't this scope guard: https://tour.dlang.org/tour/en/gems/scope-guards ?

david2ndaccount• 5 years ago

I usually use the single-exit-point idiom with gotos to handle cleanup. I now wonder if there is a compiler that helps you enforce that so you don’t randomly stick a return in the middle of your function.

Anyway, this would be great to have in C as it would simplify how resources are handled.

loeg2• 5 years ago

You can use the non-standard, but typically implemented, cleanup attribute today for function-scoped cleanup. I don’t know if compilers inline this kind of “destructor”. It works well — I’ve seen it used successfully at multiple employers.

rwmj4• 5 years ago

Not only inline it, but also optimize it away (eg. _cleanup_free char *ptr = NULL; the cleanup path just disappears in places before ptr is assigned to a non-NULL value).

95014_refugee• 5 years ago

You can use the cleanup attribute and a flag to detect early exit.

greenn• 5 years ago

If the purpose of defer is to replace the `goto single_exit`, I think the value captures are unnecessary. Any single_exit I've implemented uses the value at the time of function exit, so that I can realloc in the middle of the function.

It would be a shame if this defer was limited to function scope. It would be very useful in nested blocks as well. But, I would still appreciate it.

defer and auto are the only things I would love to see in C.

lerno• 5 years ago

I don't mind a sane defer in C, that is something which follows scope in the same way stack allocated destructors are invoked. This follows the behaviour in other languages like Swift.

Why "on function exit" style defers - already known to be a bad idea from Go - is beyond me. Such a solution more or less requires storage of potentially unbounded allocations.

    Foo *f;
    for (int i = 0; i < very_big_value; i++) {
      f = get_foo(i);
      // BOOM
      defer return_foo(f);
    }

I would sort of understand if this was proposed for a high level language garbage collection where actual memory usage is secondary.

cpuguy83• 5 years ago

In this case you wrap the loop in an anonymous function if you need it to be cleaned up within the scope of the loop. Or move the functionality to another function.

knome• 5 years ago

Adding a statement that would require a dynamic allocation for every iteration of a loop is kind of insane for C.

It doesn't matter what the defer does, if it's allocated in a for statement and doesn't go off until the surrounding function exits, then it's going to have to stuff tons of function pointers and parameters somewhere, presumably alloca'd onto the stack over and over.

That's not C. That shouldn't be C.

There are a dozen languages for doing clever dynamic magical things in code. C is still fairly straightforward. Use one of the other languages instead of bagging down C with complexity until it turns into another difficult C++ variant over time.

adamrt• 5 years ago

Why "on function exit" style defers - already known to be a bad idea from Go - is beyond me

Is there something you can point me to about this? I write Go professionally and from a readability and utility standpoint I really like it in common scenarios. I hadn't heard its a know bad idea and am just curious. Thanks.

kaba06• 5 years ago

I think parent means that there are languages with scope-based clean-up (e.g. in rust/c++ a value will be cleaned up at the end of the scope that contained it, so one can even create a separate block inside a function) which is a better choice than forcing people to do clean up at the end of the function.

skybrian2• 5 years ago

It seems like you could just ban that. Defers aren't typically used within loops, so why support it?

clysmic• 5 years ago

Sure they are, if there is something that is being acquired at the start of the loop and needs to get released at the end...

pornel• 5 years ago

Since Microsoft has decided to sabotage C by not implementing anything that isn't in C++ already, and this will never be in C++, this feature is already dead.

Projects that target only GCC and Clang can use __attribute__((cleanup)) without waiting a decade for it.

xeeeeeeeeeeenu• 5 years ago

Since Microsoft has decided to sabotage C by not implementing anything that isn't in C++ already, and this will never be in C++, this feature is already dead.

This is no longer true: https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

frankohn• 5 years ago

Yes it is still true, they just have decided to support newer c standards when they sabotaged c11 by making optional a fundamental feature like complex numbers:

Support for Complex numbers is currently not planned and their absence is enforced with the proper feature test macros.

Sadly, there is no future for the C language with a corporation like them in the committee. Much better to look at Zig or Nim, they fill more or less the same space and are developed by smart and passionate people.

emptybits• 5 years ago

I'm interested. So defer is one of the handful of achievable goals I find Zig interesting and hold some hope for it. Easy to call C from Zig or Zig from C. And Zig can also compile C and target cross-platform easily.

    const sprite_sheet_surface = c.SDL_LoadBMP("res/tile.bmp") orelse {
        c.SDL_Log("Unable to create BMP surface from file: %s", c.SDL_GetError());
        return error.SDLInitializationFailed;
    };
    defer c.SDL_FreeSurface(sprite_sheet_surface);

fshee• 5 years ago

Somewhat related: I hacked some macro up in gnu89 C to get a Go styled defer once upon a time. I felt bad for making my compiler course instructor review that code... Very convenient, though.

eqvinox2• 5 years ago

Whereas gcc’s cleanup attribute is attached to functions, POSIX’ cleanup functions and the try/finally are attached to possibly nested blocks.
This indicates that existing mechanism in compilers may have difficulties with a block model.

Erm. No. GCC's cleanup attribute is attached to nested blocks. Whatever that means for the conclusion there.

How is a pretty basic misunderstanding like this seeping into an ISO WG document?!?

[add.:] in case anyone wants to double check: https://gist.github.com/eqvinox/c062f5a46f3a60b1151fcdf3e91a...

tialaramex4• 5 years ago

An individual or handful of people make a proposal, the Working Group looks at the proposal, maybe it gets revised (this is version 2). Working Groups themselves do not, on the whole, produce documents like this.

There is no ISO magic ensuring working groups are all-knowing. There's an excellent chance that no members of WG14 have a deep in-depth knowledge of GCC, or that members who did they weren't particularly interested in that part of this paper (e.g. they were already staunchly for or against, remember ISO Working Groups are democratic, a proposal does not need consensus, so a working group member who thinks your idea is inherently good or bad might just skim the introduction, and move on)

UltraViolence• 5 years ago

C should be retired and replaced with compiled C# (if the usage allows for Garbage Collection) or Rust (if deterministic memory management is needed). There's really no use for pulling on a dead horse.

C has had its heyday and should simply curl up and die.

Shadonototra2• 5 years ago

this is the worst idea i read today, thanks

people don't understand what "programming" is about anymore

rsj_hn2• 5 years ago

I think one difference between a classically trained programmer of a few decades ago and many of the programmers today who entered from javascript or bootcamps or were even self-taught is lack of understanding about all those other systems below you. For example, do you think the OP has heard of Simple Managed C?

C# is great, but it's not a systems language, it depends on piles of C/C++/etc code in order to run.

nmilo4• 5 years ago

In 50 years everyone will have moved on to the hot new language, but your OS will still run, at least some, C code. Whether you like it or not C has enough inertia to last a really, really long time.

nrabulinski• 5 years ago

“Simple” defer feature - proceeds to implement c++ closures and semantics just to have a defer keyword which invokes them at the exit point of a scope

Shadonototra2• 5 years ago

i prefer D's approach

    scope (exit), scope (failure), scope (success)

https://tour.dlang.org/tour/en/gems/scope-guards

josephcsible2• 5 years ago

I don't like the nonlocality of this. When I see a closing curly brace, I want to be able to tell what execution will do when it gets there just by looking immediately before the corresponding opening curly brace, but now I'm going to have to look in the entire body of the block too. If I wanted things to be this implicit and nonlocal, then I'd have chosen C++ instead of C.

laserbeam4• 5 years ago

Except, when you start writing code with defers half your cleanup flags disappear, you end up with fewer branches and it makes it much harder to forget to free temporary allocations. It's really nice to look at only 1 place in code where something was allocated to ensure it also gets deallocated, instead of looking at the curly brace and then thinking: ok, what should be deallocated here, and when should it not be?

yk3• 5 years ago

I don't like it. The great advantage of C is the very simple virtual machine and therefore very easy to reason about code. This bolting on language features is the hallmark of C++, which don't get me wrong has advantages, but in case we want the advantages we can already use C++.

eptcyka• 5 years ago

The feature wouldn't introduce much complexity to the abstract machine model IMO, not any more than what cleanup labels already do.

yk3• 5 years ago

Cleanup labels are just a conditional jump, it's explicitly in the code. The defer feature would introduce implicit guarantees by the compiler.

mort96• 5 years ago

..And cleanup attributes aren't in C.

dgellow2• 5 years ago

defer has nothing to do with C++.

dahfizz• 5 years ago

C++ has try finally, which is the same thing. Instead of bloating C, anyone needing defer can use a subset of C++ that fits their needs.

usrbinbash3• 5 years ago

How does "defer" make it harder to reason about the code? Especially when the alternative is a bunch of resource-flag-tests and cleanup labels?

There is a reason why it was introduced in Go.

yk3• 5 years ago

Because the compiler has to introduce code implicitly. The control flow is usually very explicit in C, with this feature it is less explicit.

Ericson2314• 5 years ago

I dunno this capture stuff is alright but also a bit like blatant appeasement.

The point of this feature is to be non-cannonical RAII. I.e. it is about cleaning up a location. This data oriented approach is similar to how "locked data" is more correct and intuitive than "critical sections".

Now I get C being low level, so perhaps this is better, but I can't really imagine the thing I am cleaning up (as opposed to auxiliary info like an allocator to deallocate memory with) being captured by value.

BTW, speaking of moves, a "set this bool if I use this variable by value" feature would be very useful. Skip C++'s mistake and do Rust's model. Would work great with this feature.

lelanthran• 5 years ago

Now I get C being low level, so perhaps this is better, but I can't really imagine the thing I am cleaning up (as opposed to auxiliary info like an allocator to deallocate memory with) being captured by value.

I was wondering the same thing; what is the use-case for needing a capture-by-value option at scope exit?

Just make all captures a capture-by-reference and it works for all use-cases.

AndyKelley2• 5 years ago

What an arrogant use of the word "simple" in the title.

* no decision on access to variables

* lambdas are involved at all

* "appearance in blocks other than function bodies [is] implementation-defined"

They cited D in the implementation, but then used Go as the inspiration for the feature. The answer was staring them right there in the face, scope(exit) [1]. Or, you know, they could have cited Zig for the exact syntax they wanted [2].

This feature is completely unusable.

Let me demonstrate. You can't use this inside an if statement:

    if (foo) {
        const ptr = malloc(...);
        defer [&]{ free(ptr); } // implementation defined. get fucked
    }

Furthermore, it's go-style, so the defer runs at the end of the function. This is not only implementation defined, it's full-blown undefined behavior because `ptr` goes out of scope before the defer expression runs.

Scope-based defer works great. Go-based defer is already problematic enough in Go; in C it's worse than not having defer in the language at all.

[1] https://dlang.org/spec/statement.html#scope-guard-statement

[2] https://ziglang.org/documentation/0.9.0/#defer

dnautics• 5 years ago

Oh come on now, it's not completely unusable, just "unusable in a ton of important use cases".

AndyKelley2• 5 years ago

Point taken, but I will defend my claim: The few use cases where it does work are footguns because in the future, you or another collaborator will be tempted to wrap the code into a block, which is normally 100% safe for all other features of the language. It would be easy to do without thinking about it. But if you do it becomes UB as demonstrated above.

So the reasonable policy would be to use the same cleanup method everywhere, to avoid footgun firing when code is edited.

pjmlp8• 5 years ago

Yep, typical C decision design pattern.

karmakaze2• 5 years ago

The Java AutoCloseable seems like a cleaner version of the MS __try/__finally:

  try (MyCloseable c = useSomething()) {
    // stuff
  }

Why isn't this the path explored? The main difference would be not having extra nested blocks. That seems relatively minor, no? It can be improved arg list:

  try (MyCloseable c1 = useSomething(), ElseThing c2 = elseThing()) {
    // stuff
  }

CodesInChaos• 5 years ago

This syntax relies on destructors, which C doesn't have.

kaba06• 5 years ago

One could pass in a cleanup function that will be called - but this is very similar to gcc’s cleanup attribute.

karmakaze2• 5 years ago

The Java implementation doesn't use destructors. The AutoCloseable interface only has the one close() method, so for C a callable function would do.

dandotway3• 5 years ago

Features that seem like a good idea at the time often don't stand the test of time 20-30 years in the future. In the mid-90s Object-Oriented Programming was super-hyped so a bunch of other languages bolted on OO, such as Fortran and Ada. But now we have Go/Rust/Zig rejecting brittle OO taxonomies because you always end up having a DuckBilledPlatypus that "is a" Mammal and "is a" EggLayer.

A great strength of C is that if you want more features you just go to a subset of C++, no need to add them to C. C++ is the big, ambitious, kitchen-sink language. When C++ exists we don't need to bloat C.

Fortran was originally carefully designed so that people who aren't compiler experts can generate very fast (and easily parallelized) code working with arrays the intuitive and obvious way. But later Fortran added OO and pointers making it much harder to auto-parallelize and avoid aliasing slowdown. Now that GPUs are rising it turns out that the original Fortran model of everything-is-array-or-scalar works really well for automatically offloading to the GPU. GPUs don't like method-lookup tables, nor do they like lambdas which are equivalent to stateful Objects with a single Apply method.

Scientists are moving to CUDA now, which on the GPU side deletes all these features that Fortran was bloated with. Now nVidia offers proprietary CUDA Fortran which is much more in the spirit of original Fortran, deleting OO and pointers for code that runs on GPU. If the ISO standards committee didn't ruin ISO Fortran for scientific computing by bloating it with trendy features we could all be running ISO Fortran automatically on CPUs and GPUs with identical code (or just a few pragmas) and not be locked in to proprietary nVidia CUDA.

But GPUs are now mainly used for crypto greed instead of science for finding cancer cures or making more aerodynamic aircraft so maybe it all doesn't matter anyway.

mst• 5 years ago

GPUs don't like method-lookup tables, nor do they like lambdas which are equivalent to stateful Objects with a single Apply method.

Since I tend towards read-only instance data, I often live my life considering an object to mostly be a bag of closures with a shared outer scope.

bee_rider• 5 years ago

Yeah. I think I'm much less informed on this topic, but my initial thought on reading the "Rationale" section was that this sort of feature would only be helpful in cases where C offered almost no advantages over C++.

svnpenn2• 5 years ago

A great strength of C is that if you want more features you just go to a subset of C++, no need to add them to C. C++ is the big, ambitious, kitchen-sink language. When C++ exists we don't need to bloat C.

This is a rationalization, and a bad one. When your solution is "just pull in another programming language", you have a problem.

dandotway3• 5 years ago

"Another programming language" cannot even meaningfully exist if all programming languages are forced to have the same feature set. Should Python get C-like low-level pointer manipulation so that Python users don't need to "pull in another programming language" of C to do pointer manipulation?

C doesn't need "defer" because C programmers have managed since the 1970s to implement operating systems, compilers, interpreters, editors, etc., just fine without it. Those who want a bigger C can use C++, this pond is big enough for two fish.

rossy2• 5 years ago

On the other hand, some features turn out to be a very good idea and do stand the test of time. Designated initializers and compound literals, introduced in C99, are perfect examples of C features that stuck and became very widespread, while keeping the spirit of the language. C shouldn't be set in stone.

The fact that goto-based solutions and a non-standard GCC extension are common methods of resource cleanup in C today seems to suggest that a standardized language construct for resource cleanup would be appreciated.

A great strength of C is that if you want more features you just go to a subset of C++, no need to add them to C.

What is C for then? Cleanup of function-scoped resources is a major concern in every large C codebase I've seen.

eps3• 5 years ago

It's not an major concern though.

If one has trouble writing correct cleanup code conventionally (with "goto out" and a single function exit), then allowing them to use defer will only lead to more obscure issues.

And if defer is meant to make code slimmer, it still doesn't belong to C, because it leads to implicit execution and memory/stack allocation.

C is an explicit and verbose language. What you see is what you get. This is the spirit of the language. Unlike with, say, C++ where "a + b" may actually produce kilobytes of machine code, because + just happend to be overloaded.

Animats• 5 years ago

That doesn't belong in C. C doesn't have much in the way of implicit execution. C++ does, and C++ already has destructors.

AlbertoGP• 5 years ago

I list a few defer-style approaches for C that I know of, including the previous version of this one, in the “Related work” section of my block-based defer for C (presented in HN last August https://news.ycombinator.com/item?id=28166125):

https://sentido-labs.com/en/library/cedro/202106171400/#defe...

abaines• 5 years ago

I feel as though they should change the name of the paper, because this must be one of the most complex takes on 'defer' that I have seen.

They make a classic mistake of trying to solve a problem by adding more complexity. They cannot decide on by-value or by-reference, so they take the convoluted C++ syntax to allow specifying one (as well as other semantics?).

It does not fit with C in my opinion. It will also hurt third party tools that wish to understand C source code, because they must inherit this complexity.

I would prefer a solution where they simply pick one (by ref / by value) and issue a compiler warning if the programmer has misunderstood. For example, pick by-value and issue a warning if a variable used inside the defer is reassigned later in the scope.

tedunangst• 5 years ago

I think people are getting hung up on the lambda syntax, but it seems they're just taking what they're given. If c23 adds lambdas, at this point I'd say it's more likely to be c++ syntax than c syntax because c++ is already out there. So instead of "to resolve ambiguity we force user to choose" it's more like "the probable lambda syntax already makes this explicit so we will use it too." I think that makes more sense than two different syntaxes for lambda and defer, whatever the other merits of the proposal.

unwind2• 5 years ago

In all of those examples that talked about which pointer value to capture, it would perhaps have helped to use the built-in (standard, although in my opinion way too few programmers use it) way of indicating that a value won't change, i.e. const:

    double * const q = malloc(something);
    /* use whatever magic new syntax here, 'q' will not change in this scope */

That wasn't so hard, in my opinion. They could simply let 'defer' fail if the referenced pointer isn't constant. Also, as a micro-wtf I was confused by the use of 'double', for a generic allocation I would have expected void.

foxfluff14• 5 years ago

So then you can't for example use defer with a pointer that may get realloc'd in a loop? Or pointer to the root node of tree-to-be-built? What a half-assed defer, in my opinion.

unwind2• 5 years ago

Sure, that's a valid point. I confess to being not at all used to thinking of/using 'defer' so I don't have a good grasp of the use cases. Thanks.

nrclark3• 5 years ago

C could really use a standardized defer feature.

I don't like the proposed syntax though, because it introduces a new meaning for the & operator. In all other uses, the & operator modifies the type of the operand, to be the opposite of the * operator.

In the proposed syntax, & becomes something a little bit different: a C++-style reference. I think it would introduce too much language confusion.

A more C-like syntax would be:

defer(captures-by-value; captures-by-reference) {}.

Defer() statements would be executed at scope-exit, in last-in first-out order. Standard block scoping would apply for anything declared inside of the defer().

KerrAvon2• 5 years ago

The & syntax builds on a separate proposal for C++-style lambdas in C which would introduce that syntax generally.

SeanLuke• 5 years ago

Given C++'s grotesque track record of insane new syntax, this wouldn't seem to be an advantage.

pantalaimon• 5 years ago

We are not using teletypes anymore, the days of confusing single character keywords should truly be over.

isaiahg• 5 years ago

Defer() statements would be executed at scope-exit, in last-in first-out order. Standard block scoping would apply for anything declared inside of the defer().

But this still doesn't address the problem the change is used to contain. Should defer free a variable's value as it is when defer is used or the value at the end of the scope.

And is it really such huge change. I don't find it too far removed that it becomes confusing and I appreciate the additional control over what should be freed and where. You can imagine a scenario where a variable is being reused multiple times where this kind of additional control might be useful.

nrclark3• 5 years ago

That's the capture-by-reference vs capture-by-value distinction in a nutshell, yes.

Capture-by-value takes a snapshot of the value instantly, and stores it until the block is executed.

Capture-by-reference waits to evaluate the variable until the block is executed.

Between the two, capture-by-reference is the least surprising behavior IMO. It acts like the deferred code is copy/pasted onto the end of the function.

Capture-by-value is the most flexible, and can also emulate capture-by-reference by using pointers. Any syntax should either support both, or only capture-by-value.

yason• 5 years ago

I like your C-like syntax better.

But I don't think there's any need to differentiate between different captures. Capture by value is enough because what do you need in C if you need a reference? Capture the value of the pointer.

    {
        void *chunk = malloc(x);
        
        defer (chunk, void **reference = &chunk) { ... }
        
        ...
    }

This would allow you to operate on the value both from the defer declaration time and defer execution time, whichever it is that you need.

nrclark3• 5 years ago

That's an interesting point, and very C-like. You're right that capture-by-value can emulate capture-by-reference.

Capture-by-value does have a weakness though, in that it requires allocation (whether stack or heap). Capture-by-reference doesn't have any storage overhead.

In my example, I suggested having both. But if we had to pick only one, capture-by-value would be the one to use.

krapp• 5 years ago

I disagree. Every programming language is suffering from bloat and complexity now. We need one language, at least, to stand up against the madness and remain simple and stupid, even to the point of being dangerous - the old man yelling yelling at clouds of programming languages. That language could have been javascript, before all the nonsense with classes and templates and integers, but now maybe it should be C. Like, C doesn't even know what a string is, and I respect that. What even is a "string?" Sounds like unnecessary complexity to me. Raw pointers and bytes should be enough for anyone.

butterisgood• 5 years ago

C is done. It just is. It has had an amazing run and yes we will continue to write code in it - despite all the better alternatives it will probably never die.

colonwqbang• 5 years ago

Why are lambdas needed for this? The standard C idiom used for this since forever ("goto out") does not use lambdas.

daneelsan4• 5 years ago

Huh that's a good point.

mpyne• 5 years ago

The paper seems to go into this.

* There is no generic way to say whether a defer should free up a variable based on the value it has when the defer was encountered, or a potentially-different value the variable might have when the defer is actually run. * So the best thing to do seemed to be to give the programmer the ability to make the choice. * Lambdas are the means they chose to make that happen.

But this all seems to stem from a desire to enable a use case beyond what an obvious use of a goto idiom would support.

camel-cdr3• 5 years ago

Because there are multiple defer proposals and this one is made to be compatible with the lambda proposals. N2589 for example proposes a simpler defer statement that just defers an expression, so e.g. "defer fclose(f);"

daneelsan4• 5 years ago

Some say they don't like it because it it's implicit control flow, i.e. I don't like that my code is being put into the end of the function without it being in the end of the function. I mean OK, but that's what for loops so right? The i++ is put at the end of the "while" loop, together with the exit condition. I think the more important problems are: 1) why be function scoped and not block scoped? 2)why should it be so tied up with lambdas?

1) I don't se why they chose function over scoped so please enlighten me 2) the proposal said there were debates whether defer free(ptr) refers to the ptr where the defer first appears, or to the current ptr that appears when the defer block is being executed. As someone mentioned, gotos already work in the latter way. Same goes with i++ in a for loop, I could do whatever I wanted with the i inside the for, and the i++ or the exit condition would use the latest value of i, not the value at the start of the block.

laserbeam4• 5 years ago

Some say they don't like it because it it's implicit control flow, i.e. I don't like that my code is being put into the end of the function without it being in the end of the function.

Wait, what? The whole point of defer is to let you do that. People like defer because it's different control flow. If that's why X doesn't like defer, X shouldn't use it. No big deal.

daneelsan4• 5 years ago

Yeah, I do want some kind of defer.

camel-cdr3• 5 years ago

I don't se why they chose function over scoped so please enlighten me

I don't like it either, but it allows for a simpler syntax, consider e.g. "f = fopen(...); if (f) { defer fclose(); }". You'd need special syntax for the defer to escape the block. Although this example is a bit forced, because usually you'd return from the function on error anyways.

dataangel5• 5 years ago

It's annoying to see everyone adopting defer (Jai, Go, Zig) and not destructors. Destructors are strictly more powerful. Defer only lets you delay something based on scope, while destructors let you delay based on object lifetime, which might be tied to scope (for an object allocated on the stack) but could also be on the heap. With destructors you can have a smart pointer type where you can't screw up the incrementing and decrementing, with defer you cannot do this.

typon• 5 years ago

This is actually a feature, not a bug. With defer the control flow is more obvious and predictable. That’s one of the reasons new languages are adopting it.

gsliepen• 5 years ago

But with defer you can easily get the order of things wrong, whereas destructors are automatically called in the correct order.

naasking• 5 years ago

Destructors are a lot more complicated for that reason, and the semantics may not always be clear.

foxfluff14• 5 years ago

Certainly if the only thing I want to do is to make sure a piece of code runs when I leave the block or function, defer is the most direct way to do it. I don't care for "strictly more powerful" if it requires something as roundabout as defining an (zero-sized) object with a destructor and allocating an instance of it..

monocasa4• 5 years ago

Allocating doesn't mean heap allocation. A zero sized auto allocated object is free in C today.

dataangel5• 5 years ago

It's true it's less typing, but it's not too hard to engineer a macro on top of destructors to get defer behavior (C++ at least will let you define a type inside a function, so the macro can expand to a trivial type with a destructor containing the users code then make a dummy instance on the stack). It is however impossible to do it the other direction. Also no reason we can't have both.

von_lohengramm• 5 years ago

Destructors bring about complications with lifetimes and move vs copy semantics among other things. Simple scope-based defers are trivially understandable (if you don't abuse text replace macros...) and are mostly just syntactic sugar allowing for better, more maintainable code in almost all codebases. IMO seeing such an overcomplicated version of defer even being considered for C is embarrassing to say the least.

dataangel5• 5 years ago

C++ and Rust both have both move and copy semantics and destructors. What's the issue?

taeber2• 5 years ago

I like the idea of automatic resource cleanup in C and was excited when I read the headline, but I agree with others that the proposed syntax doesn't seem very C-like.

I previously shared a "with" statement idea on HN that I thought fit with the rest of the language.

  with (FILE *fp; fp = fopen(path, "wb"); fclose(fp)) {
  ...
  } else {
    perror("Failed to open file");
  }

https://github.com/taeber/cwith

https://news.ycombinator.com/item?id=23370693

edit: formatting

okla3• 5 years ago

I wonder if this can be emulated with for loop:

  for(FILE *fp = fopen(path, "wb");
      fp != NULL;
      fclose(fp), fp = NULL) {
    ...
  }

josephcsible2• 5 years ago

No, because exiting the block early (e.g., with return) won't run the cleanup code.

taeber2• 5 years ago

I'm glad you suggested that, because one of the first comparisons I drew in my article[1] about the "with"-syntax was how it looks like a for-loop.

If you are interested, I did provide a few macros[2], but as another commenter pointed out, they won't handle an early return. You can use "break" to exit early though:

  #define with(declare, startup, cleanup, block) \
      {                      \
          declare;           \
          if (( startup )) { \
              do {           \
                  block;     \
              } while(0);    \
              cleanup;       \
          }                  \
      }

  with (FILE *fp, fp = fopen(path, "rb"), fclose(fp), {
    fread(buf, 1, sizeof(buf)-1, fp);
    if (ferror(fp)) {
      perror(path);
      break;
    }
    printf("%s\n", buf);
    success = 1;
  })

There's also "withif"

  #define withif(declare, startup, cleanup, block, otherwise) \
      {                      \
          declare;           \
          if (( startup )) { \
              do {           \
                  block;     \
              } while(0);    \
              cleanup;       \
          } otherwise;       \
      }

[1]https://github.com/taeber/cwith

[2]https://github.com/taeber/cwith/blob/master/with.h

camgunz2• 5 years ago

Why is this feature entangled with lambdas? Why is defer not a block which is sugar for a goto? Probably the answer is "we want capturing" but this only exists in Go because of its defer scoping weirdness. It also doesn't make the feature foolproof, as in what if I call fclose() outside the defer lambda? Also lambdas and capturing aren't free? What allocates space for them? What is going on with this feature?

arka2147483647• 5 years ago

Goto may cross variable initialization, so the code in goto may use a variable that does not exist, theoretically.

Also a goto cleanup becomes complex if you have, say a dozen variables to cleanup.

Anyway, i think this is really syntaxtic sugar for the Cpp destructor. I peresume that the lambda will create an object, which will hook itself to the same mechanism that calls cpp destructors at the end of blocks.

And, as all major c compilers are also cpp compilers this seems a good idea to me. And ofcourse the lamda syntax seems same as cpp. So rhats where all this comes from.

camel-cdr3• 5 years ago

camgunz2• 5 years ago

Ahhhhh thank you. I had a minor freak out, thanks for the good info!

hgs3• 5 years ago

Yes! I've been waiting for C to get a defer statement. However, my opinion of this proposal hinges on whether the implementation of lambdas requires runtime support. Not all systems running C have access to the C standard library, much less a runtime to manage lambdas (depending upon how they are implemented). Ideally defer would entirely be handled at compile time.

laserbeam4• 5 years ago

This indicates that existing mechanism in compilers may have difficulties with a block model. So we only require it to be implemented for function bodies and make it implementation-defined if it is also offered for internal blocks.

Can someone explain to me how a feature used for freeing memory, closing file descriptors, releasing locks and all other cleanup scenarios are now possibly entering undefined behavior territory? I get that's not the intent but... Ugh...

foxfluff14• 5 years ago

Implementation defined is quite different from undefined...

But I agree, making this bit implementation defined is not cool. I don't have strong opinions on whether defer should be in C or not. It does seem like a potentially useful feature. Whatever they do though, I think they should do it right or not do it at all. The last thing I want is to bloat the language with half-assed features that you can't use half the time because they're not defined well enough. If people want implementation defined features, geez, just keep using compiler extensions until the WG can define a proper standard.

Apart from this bit, the proposal seems pretty decent to me. I kinda like the lambda syntax and the control it gives you over the value you capture. Just make it block scoped and don't leave it implementation defined.

jibalt5• 5 years ago

Is it April 1 already?

"Whereas gcc’s cleanup attribute is attached to functions, POSIX’ cleanup functions and the try/finally are attached to possibly nested blocks.

This indicates that existing mechanism in compilers may have difficulties with a block model. So we only require it to be implemented for function bodies and make it implementation-defined if it is also offered for internal blocks.

Nevertheless, we think that it is important that the semantics for the feature are clearly specified for the case of blocks, such that all implementations that do offer such a feature follow the same semantics. Therefore it is also a constraint violation to ask for the feature for blocks on implementations that don’t have support for it."

To call this incompetent would be too kind. Completely wrong about the scope of gcc's cleanup attribute, wrong to omit the prior art from Dlang, utterly wrong about what it "indicates", wrong about making it implementation-defined ... and that's just this one section.

A simple defer feature for C

Related Stories