My only complaint is I wish they didn't name it `unsafe` and instead named it something like `compiler_unverifiable` so that people could more properly understand that we can make safe abstractions around what the compiler can't verify.
I like the word `unsafe`. It's a nice red flag to newbies that "you almost certainly shouldn't use this" and once you have enough experience to use `unsafe` well you'll know its subtleties well enough.
I just saw a tweet from Esteban Küber[0] the other day that made me rethink a silly thing I did:
"I started learning Rust in 2015. I've been using it since 2016. I've been a compiler team member since 2017. I've been paid to write Rust code since 2018.
I have needed to use `unsafe` <5 times.
That's what why Rust's safety guarantees matter despite the existence of `unsafe`."
For me, I was being a bit lazy with loading some config on program startup that would never change, so I used a `static mut` which requires `unsafe` to access. Turns out I was able to figure out a way to pass my data around with an `Arc<T>`. I think either way would have worked, but I figured I should avoid the unsafe approach anyway.
Yeah if you don't need mutation after initialization is done, Arc<T> is a good option for sharing. Lazy<T> (https://docs.rs/once_cell/latest/once_cell/sync/struct.Lazy....) is also nice, especially if you want to keep treating it like a global. I believe something like Lazy<T> is eventually going to be included in the standard library.
I don't think newbies using it would be a problem. There is an issue with people/companies evaluating Rust and stopping when they see `unsafe` without looking much further into it.
I believe the term "unsafe" in this sense predates Rust. Haskell's GHC has unsafePerformIO [1], which is very similar conceptually. Generally used to implement an algorithm in a way where it can be pure/safe in practice, but where this cannot be proved by the type system.
If I were to go back and do it again I'd propose to rename unsafe blocks to something like `promise`, to indicate that the programmer is promising to uphold some invariants (the keyword on function declarations would still be `unsafe`). (Of course the idea of a "promise" means something different in JavaScript land, but I'm not worried about confusion there.)
That's inaccurate, because Rust still performs all the usual checks inside of unsafe blocks. The idea that unsafe blocks are "turning off" some aspect of the language is a persistent misconception, so it's best to pick a keyword that doesn't reinforce that.
That’s right, the keyword enables additional operations, namely those that can’t be checked — which one might even call “unchecked operations” to justify the keyword.
My problem with the word “unsafe” is that many people seem to think unsafe code blocks necessarily have security issues. Hence the bullying of library authors even in cases where the authors did their homework.
Anything about the mechanics of the implementation is a second-order detail compared to that, as far as I’m concerned.
Shrug. I really don't think unchecked is "wrong" in spirit, since adding an unsafe block makes it trivial to write code which ignores the usual boundary and pointer lifetime checks, which is not very different in practice from turning off checks. Also unsafe code is usually wrong, and deeply difficult to write correctly, much more so than C.
Also, I dislike the word "unsafe" since "unsafe code" is easily (mis)interpreted to mean "invalid/UB code", but "invalid/UB code" is officially called "unsound" rather than "unsafe". Unsafe blocks are used to call unsafe functions etc. (they pass information into unchecked operations via arguments), and unsafe trait impls are used by generic/etc. unsafe code like threading primitives (unsafe trait impls pass information into unchecked operations via return values or side effects).
unchecked would make a good keyword name for blocks calling unchecked operations, but I'm not so sure about using it for functions or traits.
I think the benefit of the name "unsafe" is that it immediately tells newer users that the code inside has deeper magic than they may be comfortable using. Where "trusted" is what the writer attests to the compiler, "unsafe" is what writer warnings to a future reader.
