> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst.

Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necessarily a value judgment. In that context, "unsafe" just means "the compiler can't guarantee the behavior that it can normally guarantee".

You are correct.

That doesn't mean that people will incorrectly interpret it, though.

Ada’s language is probably clearer and less loaded: checked and unchecked.

Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names.

The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)

I don't think it's bikeshedding. It does seem to be contributing to the dogmatism I'm seeing from the Rust community here, and this community reaction is a huge problem for Rust. So it matters.

Bike shedding is a structural description, not a value judgement. It’s about technical complexity, and changing a keyword is one of the most minimally complex bits of language design.

My point isn't to argue over the definition of bike shedding. If the name of this keyword is contributing to this undesirable community outburst, then its name matters, and discussions about its name are important. That's all I'm saying. If that's what you originally meant, then we are on the same page :).

We are on the same page, yes.

Back then Rust did not have editions. I think it would be worth exploring renaming `unsafe` blocks to "sound", because when one writes `sound { ... }` what one is actually stating is that the code in the block has been proven sound.

The `unsafe` function type modifier can be left as unsafe, or renamed to unsound, since that what that is doing is stating that a particular function is not always sound to call.

Points well taken, but I think "unsafe" turns it into a value judgment, especially (as samatman says adjacent) since it isn't necessarily really unsafe.

It is unsafe. There are just multiple definitions of unsafe being used here. I agree that it's unfortunate that the meaning of the keyword is easy to misinterpret.

Given the background of the people who designed Rust, I don't think it's reasonable to just assume that the keyword "unsafe" has an implicit value judgment.

It absolutely includes value judgement. You just described a form of value judgement too. You're saying that predictable generated code behavior is preferred to unpredictable generated code behavior.

> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment.

`unsafe` is a PL term that refers to _soundness_. In Rust, an `unsafe { ... }` block is required to perform an `unsafe` operation, and it precisely means "The code in this block has been proven _sound_". If the code in the block turns out to be _unsound_, e.g., because the proof is incorrect, or non-existent, then the whole program is unsound, and there is nothing that can be said about the execution of such program (usually known as "the execution exhibits undefined behavior").

For example, the Rust compiler has a lint that requires you to write a soundness proof on every `unsafe { ... }` block, explaining why that is sound, and all changes to the compiler are gated on that.

In your own projects, you can obviously do whatever you want, but for any non-trivial amount of unsafe code, without a proof, you are basically just building castles in the air.

That's an interesting way too look at it. But that's not how it works in practice. Almost no one in industry is going to write proofs for their unsafe code. It didn't happen for C or C++ and it won't happen for Rust.

In Rust you at least know where to look at, whereas in C/C++ all code can be "unsafe". With that said, writing unsafe Rust is much easier to screw up than C/C++, since you have to uphold more invariants in unsafe Rust than in C to avoid UB (like never having two mutable references to the same thing at the same time. The very issue which was raised in the actix repository)

This is how it works in practice for the Rust compiler for the Rust standard library, and for a lot of foundational crates in crates.io. (Pretty much every well reviewed crate in cargo crate review either does this, or does not contain any unsafe code at all).

We also have tools that change for this for very large projects (e.g. cargo-geiger), and tools that help you test your proofs (e.g. cargo-miri). For some unsafe components, there are also proofs in Coq, and the proof systems for Rust unsafe code are making a lot of progress in both defining the rules that unsafe code must uphold in the unsafe-code-guidelines and the Rust spec, as well as in providing example proofs and a standard library of theorems that you can reuse for your own proofs.

I didn't say it no one will do it. I said almost no one. The Rust compiler is about as far from a normal project as can be. I would like to see this changed but really I have never even seen a proof requirement when looking at Rust jobs. Not even once.

> I would like to see this changed but really I have never even seen a proof requirement when looking at Rust jobs. Not even once.

?

Any B.Sc. in CS can do most of the unsafe proofs in a one liner. All crates I maintain require unsafe blocks to be commented with a proof, for most of them the proofs are trivial, and for all of them that weren't, the unsafe code was correct, and the correct one had a trivial proof.

It's fine that YOU do it. But how many unsafe blocks have a proof in the entire Rust ecosystem (read all crates). 5% maybe? I'm not sure what your point is that any B.Sc. in CS can do it.

Rust didn’t introduce this language, they adopted it. Memory safety has been called that as long as I’ve been programming.

Using the antonym of safe was a natural move, though with the benefit of hindsight, `danger` would have been a better keyword.

After all, good unsafe code isn’t unsafe! It is dangerous though, because it forgoes guarantees of memory and resource safety provided by the compiler.