> 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".
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 :).
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.
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".