Clarify when safety may rely on correctness#523
Conversation
This is a follow-up of rust-lang#294 which in my opinion did not completely address the confusion. The "Safe Rust client" terminology comes from the [Reference](https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.soundness). I did not find official traces for "downstream" and "dependencies" but I believe they can be understood. I'm happy to follow any suggestions if those terms are still confusing.
| On the other hand, Unsafe Rust cannot trust Safe Rust without care. It can | ||
| trust Safe Rust dependencies but cannot trust Safe Rust clients. |
There was a problem hiding this comment.
Maybe it'd be better to describe what cannot be trusted a bit more specific.
| On the other hand, Unsafe Rust cannot trust Safe Rust without care. It can | |
| trust Safe Rust dependencies but cannot trust Safe Rust clients. | |
| On the other hand, Unsafe Rust cannot trust Safe Rust without care. It can | |
| trust specific Safe Rust implementations, but not arbitrary Safe Rust chosen | |
| or supplied by clients. |
There was a problem hiding this comment.
What do you mean by "implementation"? My understanding is that it means a specific version of the code that implements an API. If that's true then Unsafe Rust can trust arbitrary implementations of the crates it depends on, it doesn't need to be a specific implementation.
If we want to be more specific, this could look like:
- Unsafe Rust can trust Safe Rust within its own crate (because the implementation is known and thus can be verified to be correct) and the crates of its dependencies (because, while unknown, the implementation is trusted to be correct).
- Unsafe Rust cannot trust Safe Rust within the crates of its reverse-dependencies (because the implementation is unknown and not trusted to be correct).
Not sure how to formulate this elegantly.
There was a problem hiding this comment.
I reformulated by avoiding both the word "dependencies" and "implementations", simply using the word "clients" in the opposite direction. Does this sound better?
There was a problem hiding this comment.
Yeah the current looks great! What I meant is a bounded body of code that the unsafe code has chosen to rely on as part of its trusted base.
| This difference also holds for arbitrary implementations of one very specific | ||
| dependency. Unsafe Rust in crate `foo` (which depends on crate `bar`) may rely on | ||
| Safe Rust in crate `bar` to be written correctly, regardless of the actual | ||
| implementation. |
There was a problem hiding this comment.
How about this wording? I'd avoid using two words, dependency and crate in the same paragraph.
| This difference also holds for arbitrary implementations of one very specific | |
| dependency. Unsafe Rust in crate `foo` (which depends on crate `bar`) may rely on | |
| Safe Rust in crate `bar` to be written correctly, regardless of the actual | |
| implementation. | |
| The same can be true across crate boundaries. Unsafe Rust in crate `foo` may | |
| trust a specific Safe Rust implementation in crate `bar` when that is a | |
| bounded piece of code that can be reviewed. |
There was a problem hiding this comment.
The wording is much better, but the "specific implementation" issue from the other comment is still present. So I'll wait until we clarify that to update this part. Maybe "implementation" is more a general concept than I think.
ia0
left a comment
ia0
left a comment
There was a problem hiding this comment.
Thanks for the review! Before applying the suggestions, I have one clarification question in one of the comment.
| On the other hand, Unsafe Rust cannot trust Safe Rust without care. It can | ||
| trust Safe Rust dependencies but cannot trust Safe Rust clients. |
There was a problem hiding this comment.
What do you mean by "implementation"? My understanding is that it means a specific version of the code that implements an API. If that's true then Unsafe Rust can trust arbitrary implementations of the crates it depends on, it doesn't need to be a specific implementation.
If we want to be more specific, this could look like:
- Unsafe Rust can trust Safe Rust within its own crate (because the implementation is known and thus can be verified to be correct) and the crates of its dependencies (because, while unknown, the implementation is trusted to be correct).
- Unsafe Rust cannot trust Safe Rust within the crates of its reverse-dependencies (because the implementation is unknown and not trusted to be correct).
Not sure how to formulate this elegantly.
| This difference also holds for arbitrary implementations of one very specific | ||
| dependency. Unsafe Rust in crate `foo` (which depends on crate `bar`) may rely on | ||
| Safe Rust in crate `bar` to be written correctly, regardless of the actual | ||
| implementation. |
There was a problem hiding this comment.
The wording is much better, but the "specific implementation" issue from the other comment is still present. So I'll wait until we clarify that to update this part. Maybe "implementation" is more a general concept than I think.
JohnTitor
left a comment
JohnTitor
left a comment
There was a problem hiding this comment.
Thank you and sorry for the delay!
|
Thanks for the review! |
Update books ## rust-lang/nomicon 1 commits in cc6a6bae8c3bfa389974e533c54694662c1a9de6..5012a37c682b26c4e19433888ed2ca9b129696ca 2026-06-25 10:05:58 UTC to 2026-06-25 10:05:58 UTC - Clarify when safety may rely on correctness (rust-lang/nomicon#523) ## rust-lang/reference 10 commits in 2c27905c15a51983b54d84f050d3bda096194d27..86635e30bf861a038dc197d7e16fd09e7e514e7a 2026-06-25 17:00:32 UTC to 2026-06-16 18:56:35 UTC - use-declarations.md: move example to where it's described (rust-lang/reference#2295) - fix link target (rust-lang/reference#2299) - remove broken text (rust-lang/reference#2297) - type-layout: rewrite `#[repr(C)]` struct layout algorithm (rust-lang/reference#2243) - Fix grammar rules containing or pertaining to bounds (rust-lang/reference#2257) - Document metadata of ptrs to indirectly unsized types (rust-lang/reference#2289) - Generalize the wide-pointer total-size bound (rust-lang/reference#2290) - Cover `str` in the wide-pointer metadata rule (rust-lang/reference#2288) - Define an unsized tail (rust-lang/reference#2287) - Define pointer metadata (rust-lang/reference#2286)
Rollup merge of #158571 - rustbot:docs-update, r=ehuss Update books ## rust-lang/nomicon 1 commits in cc6a6bae8c3bfa389974e533c54694662c1a9de6..5012a37c682b26c4e19433888ed2ca9b129696ca 2026-06-25 10:05:58 UTC to 2026-06-25 10:05:58 UTC - Clarify when safety may rely on correctness (rust-lang/nomicon#523) ## rust-lang/reference 10 commits in 2c27905c15a51983b54d84f050d3bda096194d27..86635e30bf861a038dc197d7e16fd09e7e514e7a 2026-06-25 17:00:32 UTC to 2026-06-16 18:56:35 UTC - use-declarations.md: move example to where it's described (rust-lang/reference#2295) - fix link target (rust-lang/reference#2299) - remove broken text (rust-lang/reference#2297) - type-layout: rewrite `#[repr(C)]` struct layout algorithm (rust-lang/reference#2243) - Fix grammar rules containing or pertaining to bounds (rust-lang/reference#2257) - Document metadata of ptrs to indirectly unsized types (rust-lang/reference#2289) - Generalize the wide-pointer total-size bound (rust-lang/reference#2290) - Cover `str` in the wide-pointer metadata rule (rust-lang/reference#2288) - Define an unsized tail (rust-lang/reference#2287) - Define pointer metadata (rust-lang/reference#2286)
2 participants
This is a follow-up of #294 which in my opinion did not completely address the confusion.
The "Safe Rust client" terminology comes from the Reference. I'm using "dependencies" (think upstream code) as the opposite concept of "clients" (think downstream code). I'm happy to follow any suggestions to improve those terms.