My point was that programmer mistakes are something that cannot be dismissed, so waving away memory leaks as just "logic errors" means one needs to wave away other sorts of bugs for the same reason.
The Rust team regards panics as contract violations (programmer errors): for instance, with
unwrap, the programmer should be sure that the
Option will be
Some, and thus if it ever panics the programmer made a mistake, believing that a
None could never occur (e.g. insufficient input validation). Similarly, a programmer could incorrectly assume that their graph processing code avoids reference cycles, but carefully constructed input might be able to cause one to happen.
Being a little facetious:
even Rust has cases, when successfully compiled code will leak memory - "forget", strong reference cycles and others.
As my article mentions, Rust does put effort into reducing memory leaks via RAII, but RAII (and hence Rust) does not ensure that no leaks are possible. Rust may guarantee that local variables never leak when they go out of scope by running destructors automatically (unless the value has been moved out, of course), but that is covering just one way to leak memory: it is a common one, but it isn't the only one. Having this guarantee about one possibility is good, but it doesn't mean there's a guarantee about all possibilities.
To reiterate the article:
std::mem::forget is safe, and hence memory leaks are not outlawed in safe Rust.