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.

Technically, code that contains UB is just UB, and unsound code is code that allows you to trigger UB using safe code only.

For example, this is UB:

  unsafe { std::hint::unreachable_unchecked() };

And this is an unsound code, that may not contain any UB if I call `unsound()` with `false`:

  fn unsound(trigger: bool) {
      if trigger { unsafe { std::hint::unreachable_unchecked() }; }
  }