You can play with defer in Linux/VM with slimcc[1] today! It only diverges from the TS in keyword being _Defer, as well as several goto constraint violations not detected, bright side is you can witness why they are constraint violations...
The Defer Technical Specification: It Is Time
41–50 of 77 posts
Re: The Defer Technical Specification: It Is Time
#42Ever since I started working with Zig, I came to realization that its errdefer is even more useful than defer itself. But you can't implement errdefer in C, since there is no standard/disambiguous way of returning errors.
Can you expand on how errdefer works in zig? I'm not familiar.
https://ziglang.org/documentation/master/#errdefer
defer always executes on scope exit, errdefer executes on an error exit. In principle, this is similar to the logic of a try/catch/finally:
try {
// whatever
} catch {
// errdefer would belong here
} finally {
// defer would happen here
}Re: The Defer Technical Specification: It Is Time
#43I've been doing properly scoped defers in C since forever, as long as you have access to cleanup attributes and nested functions it's no big deal. https://github.com/codr7/hacktical-c/tree/main/macro
Yes, the proposal is tailored so that other than simple syntax support no new semantics need to be implemented within GCC to support defer, though clang will need to finally add support for nested functions--in spirit if not the literal GCC extension.[1] The proposal also gives consideration to MSVC's try/finally to minimize the amount of effort required there to support defer. [1] Because defer takes a block , not a…
>the proposal is tailored so that other than simple syntax support no new semantics need to be implemented within GCC
Not just GCC, but you're right it's tailored, to the same "unwinding" queue that C++ destructor, stack-VLA de-allocation and __attribute__((cleanup)) shared, won't fit into the current state of language otherwise.
Clang share more frontend between C and C++ so I imagine they can implement it as hidden C++ lambda scope-guards, the nested scenario is just full-capturing lambdas inside another.
Re: The Defer Technical Specification: It Is Time
#44The author takes great care to rebut a common theme among objections to the proposal - “this isn’t necessary if you just write code better”. I am reminded of this fantastic essay: > If we flew planes like we write code, we’d have daily crashes, of course, but beyond that, the response to every plane crash would be: “only a bad pilot blames their plane!” > This doesn’t happen in aviation, because in aviation we have d…
Defer is often quite nice when you have many return paths but it also seems fairly limited if our goal is to assume human error is unavoidable. Ruby block-based stuff or "with" in Python seem like the clear winner there.
Re: The Defer Technical Specification: It Is Time
#45Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.
It's definitely a footgun but I think it's also pretty clear in go docs that defer is a function-return-time thing, versus a loop iteration thing. "A defer statement defers the execution of a function until the surrounding function returns." from https://go.dev/tour/flowcontrol/12
I think per scope-level is probably better, but honestly still - as a I mention elsewhere - still something that seems fairly limited compared to writing code inside blocks that clean themselves up in the Ruby world. The more we're messing with scope, the more it seems like it would be possible to go all the way to that? The go-style defer appears likely to be simpler from an implementation POV; if we're gonna make it harder let's go all the way!
I know a lot of people hate the nesting of indentation from that, but it makes so many other things harder to screw up.
Re: The Defer Technical Specification: It Is Time
#46Ever since I started working with Zig, I came to realization that its errdefer is even more useful than defer itself. But you can't implement errdefer in C, since there is no standard/disambiguous way of returning errors.
Can you expand on how errdefer works in zig? I'm not familiar.
Zig has a special / compiler-known ADT for "value OR error". This is similar to Result in Rust. Or in C++, e.g., folly::Expected.
The Zig one is so special and compiler-blessed that there is special syntax for defer blocks that only run when the function return is an error variant of that result ADT -- errdefer.
Re: The Defer Technical Specification: It Is Time
#47Earlier quoted context omitted.
Right, C++ doesn't have "finally". But "defer" defers to when a "finally" section would run in a language that has it. I think.
That's what it does in Go too. This is totally defer in the Go sense (except they fixed the scoping issue).
Not quite. "The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”"
Defer in Go puts the deferred action on a run time to-do list that's processed at function exit. You can queue up deferred actions from a loop in Go. Not in this proposal for C.
What happens in this C proposal if you put a defer request inside a loop? Is it a compile time error, do they somehow to try to give it meaningful semantics, or is it undefined behavior?
Re: The Defer Technical Specification: It Is Time
#48Earlier quoted context omitted.
That's what it does in Go too. This is totally defer in the Go sense (except they fixed the scoping issue).
Not quite. "The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”" Defer in Go puts the deferred action on a run time to-do list that's processed at function exit. You can queue up deferred actions from a loop in Go. Not in this proposal for C. What happens in this C proposal if you put a defer request inside a loop? Is it a…
[deleted]
Re: The Defer Technical Specification: It Is Time
#49Earlier quoted context omitted.
That's what it does in Go too. This is totally defer in the Go sense (except they fixed the scoping issue).
Not quite. "The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”" Defer in Go puts the deferred action on a run time to-do list that's processed at function exit. You can queue up deferred actions from a loop in Go. Not in this proposal for C. What happens in this C proposal if you put a defer request inside a loop? Is it a…
[deleted]
Re: The Defer Technical Specification: It Is Time
#50> Here’s a basic example showing off some of its core properties Why not make the string literals in the code identify their positions in the output, to expose the behavior, rather than obfuscate it? Then the reader only has to work through the code, to see why it would have that order. It currently looks like a puzzle intended to be harder for the reader to understand than it needs to be.
I was thinking it might be clearer with defer printf("2"); printf("1"); for example.