> This is also why, in Rust, relying on drop to close a file (which ironically is the poster child for RAII) is a bad pattern.
Is it though? It ensures the fd is closed which is what you want, and if you have some form of unwinding in the language you can't really ask for more. And aborts are, if anything, worse.
It also works perfectly well for reading, there's no value to close errors then.
> Closing a file can raise errors but you can't reasonably treat errors on drop.
It's mostly useless anyway, since close does not guarantee that the data has been durably saved. If you want to know that, you need to sync the file, and in that case errors on close are mostly a waste of time:
- if you've opened the file for reading you don't care (errors are not actionable, since you can't retry closing on error)
- if you've flushed a write, you don't care (for the same reason as above)
The one case where it matters is if you care but missed it, in which case we'd need a bunch of different things:
- a version of must_use for implicit drops
- a consuming flush-and-close method on writeable files
- a separate type for readable and writeable files in order to hook both, and a suite of functions to convert back and forth because even if rust had the subtyping for you don't want to move from write to read without either flushing or explicitly opting out of it as you're moving into a "implicit drop is normal" regime
> one way to achieve that is to have the option to return Result in a drop, and if you do this then you need to handle errors at every point you drop such a variable
That is nonsensical, the entire point of drop is that it's a hook into default / implicit behaviour. How do you "handle errors" when a drop is called during a panic? It also doesn't make sense from the simple consideration that you can get drops in completely drop-unaware code.
Is it though? It ensures the fd is closed which is what you want, and if you have some form of unwinding in the language you can't really ask for more. And aborts are, if anything, worse.
It also works perfectly well for reading, there's no value to close errors then.
> Closing a file can raise errors but you can't reasonably treat errors on drop.
It's mostly useless anyway, since close does not guarantee that the data has been durably saved. If you want to know that, you need to sync the file, and in that case errors on close are mostly a waste of time:
- if you've opened the file for reading you don't care (errors are not actionable, since you can't retry closing on error)
- if you've flushed a write, you don't care (for the same reason as above)
The one case where it matters is if you care but missed it, in which case we'd need a bunch of different things:
- a version of must_use for implicit drops
- a consuming flush-and-close method on writeable files
- a separate type for readable and writeable files in order to hook both, and a suite of functions to convert back and forth because even if rust had the subtyping for you don't want to move from write to read without either flushing or explicitly opting out of it as you're moving into a "implicit drop is normal" regime
> one way to achieve that is to have the option to return Result in a drop, and if you do this then you need to handle errors at every point you drop such a variable
That is nonsensical, the entire point of drop is that it's a hook into default / implicit behaviour. How do you "handle errors" when a drop is called during a panic? It also doesn't make sense from the simple consideration that you can get drops in completely drop-unaware code.
Consuming methods is what you're looking for.