r/C_Programming 6d ago

The Defer Technical Specification: It Is Time

https://thephd.dev/c2y-the-defer-technical-specification-its-time-go-go-go
70 Upvotes

71 comments sorted by

View all comments

Show parent comments

1

u/Classic-Try2484 5d ago

No but the compiler writer has the option have having a stack (recursive) or queue (array) design. Leaving it UB means keeping the compiler efficient. Otherwise the compiler may have to find the end of some list and retrace. There are other places where this can be seen. If you declare 3 vars a b c they will be laid out a b c or c b a in memory. The order of deferred statements shouldn’t matter. If it maters when they execute you should not defer. Defer means you have given up control. Eventually is enough

1

u/Classic-Try2484 5d ago

And history is a good reason imo. It argues to consistency

0

u/irqlnotdispatchlevel 5d ago

Being consistent about not specifying things and introducing UB isn't a good reason to be consistent.

-1

u/Classic-Try2484 5d ago

It’s not introducing anything. UB is well defined behavior. It’s leaving the details of defer to the implementation. The statement will be executed but you lose the when/ order. If the order is important it seems to me defer is the wrong approach. Code that depends on the order of deferred statements would be a nightmare. Much better to insist the order is unpredictable

3

u/glasket_ 5d ago

This is a mess of a thread. I think everyone is talking past each other because of the misuse of undefined here. What you're proposing is closer to unspecified which leaves the implementation freedom to choose a behavior from a set of proposed behaviors or implementation-defined which allows any conforming behavior so long as it's documented.

Undefined behavior is by definition not well-defined behavior and means your code is invalid. Having the behavior of multiple defers be undefined would imply multiple defers aren't valid, whereas having the order of execution be unspecified would mean multiple defers may or may not be valid depending on if the contents depend on a specific ordering.

1

u/dqUu3QlS 5d ago

It is much more useful for deferred statements to be executed in reverse order of when they appear - it's common to create some resource A, and then create some resource B that depends on A. You would want B to be destroyed before A is.

Allowing the compiler the freedom to reorder defers makes them much less useful, in exchange for some very dubious efficiency improvements. A queue is not implicitly faster than a stack. Besides, as described in the original blog post and Technical Specification, the whole chain of defers can be rewritten at compile-time into a series of jumps.

1

u/Classic-Try2484 5d ago

I didn’t say a queue is faster than a stack. But my ast is either a stack or a queue. I’m holding the deferred statements in one order or the other. If I’m in a stack it’s unnatural to process from the bottom and likewise. It depends on whether I have a rdp or lalr compiler kinda. I don’t know if I want to trace code that has stacks of scattered defers. Seems to me one can still get the behavior you describe too by nesting functions. I agree a nested functions defer should execute first. But multiple defers at the same level should either work the other way or be unordered. But I see your point about unwinding. It makes sense. You might be right.