[pron]

It's clear once you know that an object implements the Drop trait, but you can't see that at the use site, ergo it's hidden (same goes for C++ destructors). Zig wants every call to be visible.

The tradeoff is between making sure you don't forget to write the cleanup call (Rust, C++) and making sure you don't forget to read the cleanup call (Zig). For low-level code I personally prefer Zig's tradeoff; others prefer the C++/Rust tradeoff.

[simonask]

A funny thing I’ve noticed is that some Rust programmers will explicitly call `std::mem::drop(…)` in tricky situations where it really matters, like releasing a mutex with complex interactions - even at the end of scope. I kind of like it whenever a lock is held for more than a few lines.

I think it’s a good compromise, because the consequences of forgetting it are way harsher. Memory leaks, deadlocks…

[pron]

> I think it’s a good compromise, because the consequences of forgetting it are way harsher.

And easier to detect. Knowing that no operation is carried out unless you can see it is important to many who do low-level programming.

But there is no one right answer. Differences between programming languages, including those between Zig and Rust, are mostly about people's personal preferences because language designers rarely make choices that are universally inferior than others. When they differ, it's because both sides are reasonable and have their proponents.

[rowanG077]

What do you mean if an object implements a drop? Whether an object implements a drop has no bearing on when it is called. I mean a developer can manually call it. But it is always clear when it is called.

[ManBeardPc]

The point is the code is on another type. Any variable could by of a type that implements some Drop logic. It is mostly called implicitly where it is used, wether you as a programmer are aware of it or not. You would need to check.

In Zig you need to call everything explicitly, meaning in the function you need to call what you want to be executed, no other code will run. The decision if you want some cleanup logic is made at the point of usage, not by the type itself.

That is the point of it, you look at a function and directly see what happens right there, not in other files/packages.

[bnolsen]

People seem to underestimate this. One of the first reasons I noticed about c++ was trying to figure out what functions were being called in an overly complex inheritance hierarchy. The next was from hidden behavior from seemingly benign looking sequence of statements. Both of these are a barrier of entry for bringing in new coders to a complex code base.