Hacker News Reader

Comment by atomashpolskiy | Hacker News Reader

It is in fact checked by both the compiler and the borrow checker. The only difference between safe and unsafe code is that the latter allows dereference of pointers and direct manipulation of memory, which may result in segfaults, memory leaks and data races.

View on HN

Maybe there is some checking but there is clearly somewhat less. This is in keeping with the general idiom (shared with Haskell and Swift, among others).

To be clear: unsafe Rust is a superset Of safe Rust. Every single safety check is still turned on in an unsafe block.

However, that superset contains things that are not checked. This has no effect on any other code though; safe code with a superfluous unsafe block acts 100% exactly the same.

The Rust compiler specifically aims to make it impossible to have segfaults, memory leaks, and data races — so to say unsafe code “is in fact checked” is at least a little misleading. The user still needs to do additional checking for memory errors in unsafe code.

Rust doesn't aim to make it impossible to have memory leaks: https://users.rust-lang.org/t/memory-leaks-are-memory-safe/5...

It at least eliminates what I'd estimate to be the most common cause of memory leaks (in C): missing a free. Which is the same guarantee that GCs provide.

The story is similar to C++. Almost all allocations are done by types that'll automatically call free in their destructors. But because there's no global GC, it's still possible to leak accidentally by creating a cycle in reference-counted smart pointers.

There is still the other most common source of memory leaks: putting data into long living (e.g. 'static) hash tables and having no plan for pruning it.

Reply on news.ycombinator.com