Resource leaks have nothing to do with safety. That's true both for memory safety and i/o safety. See for yourself with `mem::forget(File::open(...)?)`
According to: https://rust-lang.github.io/rfcs/3128-io-safety.html
Rust’s standard library almost provides I/O safety, a guarantee that if one part of a program holds a raw handle privately, other parts cannot access it.
According to the article:
I/O Safety: Ensuring that accepted TCP streams are properly closed without leaking connections.
These are not the same definition.
As I've mentioned several times [1], in Rust, the word "safety" is being abused to the point of causing confusion, and it looks like this is another instance of that.
- The easiest way to do this is mem::forget, a safe function which exists to leak memory deliberately.
- The most common real way to leak memory is to create a loop using the Rc<T> or Arc<T> reference count types. I've never seen this in any of my company's Rust code, but we don't write our own cyclic data structures, either. This is either a big deal to you, or a complete non-issue, depending on your program architecture.
Basically, "safe Rust" aims to protect you from memory corruption, undefined behavior, and data races between threads. It does not protect you from leaks, other kinds of race conditions, or (obviously) logic bugs.