seriously? write a `deinit(self: *Self)` function into your struct and explicitly call `defer obj.deinit()`. Explicit is better than implicit. And the penalty? One line of code per destroy site, plus writing the `allocator.destroy(self)` line in your deinit method. As a result of being explicit, SO many headaches are solved. What are the rules again when you have a C++ class that polymorphically inherits destruction? What were the override rules, if your child class needs to implement its destructor? What order do destructors trigger when there's more than one for stack-objects? what about in std::vector?? What about in std::map??

I'd love to see it if it can be implemented in a way that fits the language, but that remains to be seen.

Destructors are necessary for correct-by-construction coding. The only code you can be completely certain is correct is the code you didn't have to write. None of dnautics's questions ever arise. I don't have to think about them, and I can't get them wrong.

If you imagine destructors have something to do with memory management, you have much yet to learn.

Zig is doing almost everything right to become essential infrastructure, but will need to add some equivalent of destructors to get there.

... until you have to write a class yourself. Then you have to think of the complexities introduced by destructors such as copy semantics, move semantics and the destructors themselves.

You also have to deal with architectural questions such as should my file have a close method (C++) or do I always leave this to the destructor (Rust).

If I was to give an opinionated summary, a little complexity at the call site has been moved to a lot of complexity in the class implementation. Since there is, on average, one class implementation to many object uses, destructors might be considered a win. But I don't feel so strongly about it that I wouldn't consider a language for not having destructors.

That is a specific language issue. Rust doesn't share most of these concerns for instance, the only complexity is writing the Drop itself (which I agree can be subtle), but a type can't even be both Copy and Drop (and Rust has none of the Rule of X complexity of C++).

> You also have to deal with architectural questions such as should my file have a close method (C++) or do I always leave this to the destructor (Rust).

That seems less like an architectural question and more like a stylistic question.

> If I was to give an opinionated summary, a little complexity at the call site has been moved to a lot of complexity in the class implementation.

Except that's not actually true, much of the complexity you'll find in a destructor (excluding the complexities inherent and exclusive to C++ which nobody else is under any requirement to reproduce) will have to be implemented as whatever "cleanup" method is deferred. And then you need the defer system, and you need to actually call it which you can forget.

So while destructors are definitely not trivial to add to the language, defer spreads the responsibilities and complexity arounds, and increases the occurrences of possible errors, as well as the number of failure modes.

It also adds semantics ambiguities / complexities to the language: when you defer an expression, what is evaluated when? Dtors don't have that issue, you construct something according to normal language rules, then the dtor will be called at destruction.

What makes a language powerful is the ability to put essential semantics into a library where they can be got right once, so all users of the library benefit. It is worth design, implementation, testing, optimization effort if the results can be delivered over and over, in many different contexts, reliably.

Destructors are the necessary ingredient to pull transaction semantics into libraries. Without, you are left to write comments explaining users' responsibilities, and users have to read and act on them perfectly, or be wrong. With, you can code them correctly once and users have no opportunity or temptation to get them wrong.

Any interesting code involves custom classes written by less experienced developers that are only used once or twice in an application -- it is there that that the complexity of destructors hurt.

None of those complexities spill over onto destructors. They were perfect in their original conception, and are unchanged 40 years on. They evoke no regrets. No bugs trace to anything unfortunate about destructors.

This reminds me of Douglas Adams.

"The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair."

This seems to be a matter of taste with no absolute conclusion to be reached which style is better. At least until we get significantly better at analysing codebases and software quality.

Not true at all, there are always compiler errors, and in many cases you can statically check your code using an external validation system. I'd be 99.999% confident of most of the WRITTEN code of SEL-4, probably more confident than ANY code "not written" in rust, because it's been formally verified by a theorem-proving external system that enforces far more invariants that the rust compiler. To be dramatic, the rust compiler after all will not throw a fit if you write

    fn add(a: i32, b: i32) -> i32 { a - b; } 

Correctness also can be other things that you might not be able to lean on the compiler to check so easily. For example, cryptographic side channels (timing e.g.). If there is ANY ambiguity caused by the inexplicitness of the code you produce, maybe because you're not thinking about the cost of the destruction event, because, after all, you didn't write it, and there's not lexical artifact left over, it can get extremely challenging to audit for those sorts of things.

When your case is so weak, it is better not to present it.

To be fair, if we come back to this opening argument, I'm still wondering how strong the premise here is? Are destructors in fact essential to essential infrastructure as you claim in your view? I'm not sure that I'm convinced by the case as you've presented it so far. I don't think we need to look too far to find counter-examples of essential infrastructure with the highest levels of safety that achieve this safety without destructors, and where destructors would be precluded by the safety model.

Also, as someone who's done a fair amount of security work, the timing safe argument against hidden control flow is at least compelling and something to explore and not ignore out of hand. If a language design can make crypto simpler and safer to implement correctly, then I would say that's already a good indication of what the language may be able to do for less complex domains.

It is very limiting to think that destructors is the only way to solve resource scoping problem.

Both defer (and more generally scope guards) and context managers certainly do, to say nothing of try/finally.

Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.

If you want to use RAII for heap allocations you obviously need some sort of RAII wrapper for them. And smart pointers are the usual solution. But technically you can do without if you really really don't want to make dereference overridable, you can just have the "smart" bit (RAII / automatic deterministic deallocation) without the "pointer" bit.

I have seen plenty of new std::string("some") and other similar crimes in offshored code, or code without ownership that gets updated by whatever external contractor got brought in to implement 5 Jira tickets that finally got some budget assigned to them.

To be fair this isn't exclusive of C++, I have seen similar bad practices in other languages, C++ just gives more opportunities for them.

Right, but we're not discussing C++ are we? We're discussing RAII. C++'s mistakes are C++'s mistakes, adding RAII to a language doesn't imply you have to replicate C++'s mistakes, nor are C++'s mistakes issues with the concept of RAII, or destructors.

From type theory point of view, ideally RAII aware types should only compose with outher RAII types without escape hatches.

Rust and Ada do it better in this regard.

Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom; and std::string is limited (expect unicode-aware strings in '23). But a heap-allocated string object is a thing equally easy and useful to express in Rust. (Dunno about Ada: does it have any analog of destructors, yet?)

You have to remember to `free` the string explicitely.

> Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom

Is it? Isn't that going to create an `unique_ptr<char*>`?

> You have to remember to `free` the string explicitly

That is not a type problem. It is far from clear what pjmlp means here. unique_ptr should have been invented in 1985? Time machines have their own problems.

For arena allocated memory, you have to manage the lifetimes manually just as you would for C -- except that the arena itself can be lexically scoped, at least.

C++ is not a perfect language by any means, but destructors are not a mistake IMO. I too find having to manually "defer" cleanup annoying. I'm still interested in zig for the comptime features, though.

While that is true, I did not consider it worth mentioning given the context of the discussion. I still don't.

> Also destructors tie design to stack frames.

No more so than linear types.

C++ did it first, having been born at same place as UNIX and C, all major C compiler vendors quickly added it into the box.

- https://ziglang.org/learn/overview/#integration-with-c-libra...

- https://ziglang.org/documentation/master/#Import-from-C-Head...

Generics, lambdas, concepts, templates, exceptions, ....