Copying a thread I tweeted about `defer` vs. `Drop`:

> with defer:
> - whilst a bit error-prone, destruction is bound to the context and you can have non-intrusive destructors, you'll need this for APIs where you need a context to destroy a resource, so storing it in each object is infeasible

This is a valid argument and I actually have run into this myself! It's a real annoyance in Rust...

... but the thing is, this is the exception, not the rule. 99% of the time automatic Drop is what I want.

One of the neat demos I did of how Rust is better than C is that my Rust OF abstractions take care of refcounts for you, even across iterators and such. All the explicit refcounting (that nobody gets right) disappears.

In Zig, it'd come back, just as "defer" everywhere instead.

It *is* possible to forbid Drop in Rust for a type and require explicit destruction, and I'd rather do that for the 1% of cases where I need it, than have to defer the other 99%.

The Zig approach really doesn't scale for complex data structures. You can't have a generic vector or map, and just destroy it. You need to write explicit code to iterate through it and destroy every element. That's a real major pain...

Much of the time I don't even have Drop impls for my objects, or they just do one trivial thing. 99% of the cleanup code is generated by the compiler recursively calling Drop on all contained types. Having to type that out would be a lot of time wasted writing error-prone code...