# SAFETY documentation may be inconsistent with soundness verification specifications

**URL:** <https://internals.rust-lang.org/t/safety-documentation-may-be-inconsistent-with-soundness-verification-specifications/24539>\
**Category:** Unsafe Code Guidelines\
**Created:** [August 18, 2026, 12:27pm UTC](https://internals.rust-lang.org/t/safety-documentation-may-be-inconsistent-with-soundness-verification-specifications/24539 "2026-08-18T12:27:25Z")\
**Posts on this page:** 1\
**Showing post:** 40

<div class="post-metadata">

**Author:** ![ia0](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ia0/32/1396_2.png) [@ia0](https://internals.rust-lang.org/u/ia0)\
**Post date:** [August 22, 2026, 2:17pm UTC](https://internals.rust-lang.org/t/safety-documentation-may-be-inconsistent-with-soundness-verification-specifications/24539/40 "2026-08-22T14:17:52Z")

</div>

> [@Evian-Zhang](#):
>
> So this is even not in a pre-RFC state

I don't think anything from the unsafe mental model should make it to Rust. If safety contracts are properly done (which I'm pretty sure they will in 5 to 10 years), they should be able to cover everything in the unsafe mental model (which is just a type system approach to the program logic approach of safety contracts).

> [@Evian-Zhang](#):
>
> I really think there should be a comprehensive summary around the tightly-coupled concepts: `unsafe` -- SAFETY documentation -- two kinds of invariants -- soundness verification -- safety contract

I agree and we're not alone to believe so. I know other people and organizations who are also pondering writing learning materials around unsafe. That takes time: unsafe is a difficult and vast landscape. One of my hope is that some Unsafe Rust Working Group would come to life and host such information. (Note that this is different from the UCG, which goal is to figure out the Rust operational semantics. The Unsafe Rust WG would depend on the UCG.) I've been made aware of [safer-rust · GitHub](https://github.com/safer-rust) but they're [too focused on their projects and tools](https://github.com/safer-rust/rust-safety-standard/issues/8) to be useful to the whole Rust community.

> [@Evian-Zhang](#):
>
> Another example is the `robust`. Although it is vital to a proper model of library unsafety, and has been mentioned by many people, it is still not broadly discussed and I guess not broadly accepted.

There's a good reason for that. In Rust, all functions are robust, because [unsafe code may rely on their correctness](https://internals.rust-lang.org/t/conditions-for-unsafe-code-to-rely-on-correctness/23995). This means that safe code can cause UB outside its dependencies, but that's [by language design](https://internals.rust-lang.org/t/language-vision-regarding-safety-guarantees/24418). Robust becomes useful only if you care about safety, and want to prevent safe code to cause UB. This means you work in a sub-ecosystem with different policies and must review third-party crates against your policies.

> [@Evian-Zhang](#):
>
> I found that that community may be thinking that `set_len` must have all new slots initialized before call

We came to the same conclusion in this thread right? That's the standard library being conservative.

> [@Evian-Zhang](#):
>
> I don't know if that community has been aware of those concepts

I would be surprised if they're not. Those concepts usually become visible after some amount of exposure to unsafe, which they should have had.

> [@Evian-Zhang](#):
>
> However, I do think a comprehensive summary could help people **be aware of** those things

I totally agree, but what do you suggest?

---

_[View the full topic](https://internals.rust-lang.org/t/safety-documentation-may-be-inconsistent-with-soundness-verification-specifications/24539)._