zlacker

Not all that familiar with the specifics of Rust, but I assume it’s “safety” is somewhat similar to Swift’s “safety,” so type safety and memory safety, which does not mean no crashes, just that you will e.g. crash on an array OOB error rather than start writing or reading to random bits of memory.

>>Pulcin+(OP)
Rust's "safety" is memory safety. It's relatively well defined for a technical term: https://en.wikipedia.org/wiki/Memory_safety

edit:

> Yeah I was just trying to provide a clear definition, I didn't think you were implying it was BS.

(would have replied but I'm rate limited on HN - thanks dang!)

>>static+s
Sorry didn’t mean to imply that it was BS or anything with the scare quotes. More that there is a more specific meaning behind it than some laymen’s interpretation of the word safe.

I know I was a little surprised when I was learning Swift after hearing it was called safe only to experience crashes with array OOB. Took some explanation and thinking to understand what was meant by safe.

>>Pulcin+(OP)
You've got the right idea. The Rustonomicon gives a list of approximately everything that Rust considers unsound/UB (https://doc.rust-lang.org/nomicon/what-unsafe-does.html). The most common examples are:

- use after free

- breaking the aliasing rules

- causing a "data race" (e.g. writing to the same value from multiple threads without a lock)

- producing an invalid value (like a bool that's not 0 or 1)

There's some other technical stuff like "calling a foreign function with the wrong ABI", but those four above capture most of what safe Rust wants to guarantee that you never do. I contrast, the same page provides an interesting list of things that Rust doesn't consider UB and that you can do in safe code, for example:

- deadlocks and other race conditions that aren't data races

- leak memory

- overflow an integer

- abort the whole process