4 ms·

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

> 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 3y ago
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 3y ago
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 3y ago
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 3y ago
  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&edition=2021&gist=d6004cc32fa199c118378c1e984cb580 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - klabb3 3y ago
    Haha never seen that one before! Unfortunately it’s pretty radioactive, couldn’t even box that thing.

paholg 3y ago

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 3y ago

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 3y ago

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 3y ago
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&edition=2021&gist=d6004cc32fa199c118378c1e984cb580 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- klabb3 3y ago
  Haha never seen that one before! Unfortunately it’s pretty radioactive, couldn’t even box that thing.