Hacker News Reader

Comment by alfiedotwtf | Hacker News Reader

I'm talking safe as in Rust's memory safety guarantees.

As far as I understand, there is no accepted formal specification or even single source of truth for what the rust community thinks are the "rust memory safety guarantees". Only a large number of people that have completely convinced each other that "it's better than C++" with little proof and without even clearly defining their own semantics. Please correct me if I'm wrong here (a blog post does not qualify as a specification).

Relevant: https://github.com/rust-lang/rfcs/issues/1447

It's a little more subtle than that: It's "safe code must be memory safe" and "unsafe code infects the whole module". The stuff you're talking about is "what exact invariants are unsafe code supposed to uphold". Because unsafe Rust is a superset of safe Rust, that being an open question does not mean that what's meant by "Safe Rust" inside of safe Rust is up for questioning.

Work on exactly what unsafe code is expected to do is ongoing.

It's nowhere near that uncertain. "Memory safety" is hardly a subtle property and it's been well-understood since we figured out how to enforce it in garbage collected languages.

The only uncertain part is which rules unsafe code has to follow to maintain it- it currently comes down to "whatever LLVM optimizations won't break," which is in practice what C and C++ programmers deal with already. Things like your link are work to improve the situation beyond C and C++.

Reply on news.ycombinator.com