Hacker News Reader

Comment by dnautics | Hacker News Reader

> lacking destructors

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??

View on HN

I think GP means RAII, which is still an open area of discussion in Zig: https://github.com/ziglang/zig/issues/782

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

Actually, no, I mean destructors. Equivalent to Rust's Drop trait. Those are needed for RAII, but also for about everything else. (You need other things, too, to make RAII.) They were the only thing that made C++ uniquely powerful in 1985, and the only reason Rust can begin to compete. They represent the first and still only piece of runtime automation seen anywhere in the programming world. (Some would claim GC, but it doesn't do anything.)

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.

I don't have to think about them, and I can't get them wrong.

... 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.

> ... 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.

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.

You almost got there.

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.

I agree with your comment about libraries. Destructors biggest advantage is in well used libraries.

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.

There certainly are design complexities in C++, around copy and move constructors and various operators. Some of those could have been avoided, in hindsight, and new languages can.

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.

>The only code you can be completely certain is correct is the code you didn't have to write.

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.

> The only code you can be completely certain is correct is the code you didn't have to write.

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; }

but if that kind of a mistake happened in the SEL-4 codebase you bet your butt the theorem prover would be unhappy.

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.

Anybody who cannot tell whether a type has a destructor is qualified neither to code nor to audit cryptographic primitives. In any case, cryptographic timing behavior is verified by careful white-box testing, not just inspection. Any bonus destructor activity (if, e.g., somebody unqualified coded it) would show up then.

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

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

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.

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

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

What alternative doesn’t add failure opportunities and require additional work by the developer where they will crop up?

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

True, but also does RAII for heap allocated objects unless one makes use of smart pointers.

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

I don't understand the objection (?), I think there's at least one word missing, possibly more.

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.

What your obviously remark misses out is my second sentence "Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.".

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.

> What your obviously remark misses out is my second sentence "Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.".

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.

Had RAAI been properly implemented in C++, doing something like new std::string("something") should have been a compiler error.

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.

What do you imagine is typologically wrong with new std::string("pjmlp")?

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?)

> What do you imagine is typologically wrong with new std::string("pjmlp")?

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*>`?

Nope: https://en.cppreference.com/w/cpp/string/basic_string/operat...

> 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.

unique_ptr is simple and and easy to use for individually managed memory. shared_ptr can dramatically simplify some concurrent code, as well.

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.

Linear types can solve the problem. Also destructors tie design to stack frames. Limiting application for strictly nested code only.

> Linear types can solve the problem.

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.

Reply on news.ycombinator.com