[nextaccountic]

> basically every garbage collected runtime ends up with an awkward and kinda-broken version of RAII anyway (Closeable, defer, using/try-with-resources, context managers, etc).

RAII works only for the simplest case: when your cleanup takes no parameters, when the cleanup doesn't perform async operations, etc. Rust has RAII but it's unusable in async because the drop method isn't itself async (and thus may block the whole thread if it does I/O)

[paholg]

There are workarounds. You could, for example, have a drop implementation spawn a task to do the I/O and exit.

Also, if your cleanup takes parameters, you can just store them in the struct.

[Gwypaas]

In my experience async drop is a nice to have, not a must. Futures::block_on is good enough for the happy path in low stakes scenarios.

When dealing with async operations they tend to end up at a network boundary and thus the service enters distributed system land.

Now the async drop also has to handle the server crashing before the drop happens and at any time when it happens. Keeping that in mind trying to actually drop something becomes quite meaningless since you need to handle all other cases either way.

[klabb3]

I agree but does RAII necessarily imply parameter-free destruction?

Personally I love Rust’s `fn foo(self, …)`, which is just like a regular method but consumes the value.

Deallocate by default is fine, but sometimes you need to run specific destructors (linear type style). I’ve long wished for an opt-out from implicit drop semantics for resource/handle types.

[Nullabillity]

You can (kind of) emulate linear types by making `drop()` unlinkable[0]. Of course, I wouldn't recommend doing this since the error messages are awful and give no explanation at all of where the actual problem is...

[0]: https://play.rust-lang.org/?version=stable&mode=debug&editio...

[klabb3]

Haha never seen that one before! Unfortunately it’s pretty radioactive, couldn’t even box that thing.