4 ms·
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 bas
by dataangel 5y 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 5y agoThis 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 5y agoBut with defer you can easily get the order of things wrong, whereas destructors are automatically called in the correct order.
- watt 5y agoThe advantage of "defer" is that it's explicit. It's right there, and it's crystal clear when it will run. The "implicitness" and hidden nature of destructors is a disadvantage, it's the unpleasant way it can introduce behavior which might be surprising.
- naasking 5y agoDestructors are a lot more complicated for that reason, and the semantics may not always be clear.
- deleted 5y ago[deleted]
- foxfluff 5y agoCertainly 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..
- monocasa 5y agoAllocating doesn't mean heap allocation. A zero sized auto allocated object is free in C today.
- foxfluff 5y agoSure, though that's missing the point. I want "call this function later", not "allocate (and later deallocate and do stuff with) this object." Using objects with destructors is just a roundabout way to achieve the former and fails to express the intent directly. Even though it might have zero runtime cost, it's not free of conceptual baggage.
- monocasa 5y agodefer is nearly always 'I want to clean up this resource acquisition'. When it's not you should probably be using something else anyway. IMO destructors on objects representing lifetimes specify intent even better than defer does.
- foxfluff 5y agoOnly if you shoehorn some kind of object model into things that aren't inherently so. For example, though you can "acquire" locks, it's really just flipping a bit of state that already exists somewhere more than it is granting you a new something. I prefer to call it just what it is, a state change; you don't "acquire" a lock, you just lock it. Performed by a plain old function call that knows how to manipulate said state. Don't force me to accept the conceptual baggage of objects for what is a pair of bit function calls that flip a bit. That would be too opinionated for a language that isn't all about shoving OOP down my throat. defer for unlock() after a lock() makes a lot of sense.
- von_lohengramm 5y agoDestructors 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.
- dataangel 5y agoC++ and Rust both have both move and copy semantics and destructors. What's the issue?