Skip to content

Clarify when safety may rely on correctness #523

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JohnTitor merged 2 commits into from
Jun 25, 2026
Merged

Clarify when safety may rely on correctness #523

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
48bbd0f
Clarify when safety may rely on correctness
ia0 Jun 3, 2026
896fce6
Rewording
ia0 Jun 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions src/safe-unsafe-meaning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,12 +58,14 @@ interfaces built on top of these implementations can be assumed to be safe.
The need for all of this separation boils down to a single fundamental property
of Safe Rust, the *soundness property*:

**No matter what, Safe Rust can't cause Undefined Behavior.**
**No matter what, Safe Rust clients can't cause Undefined Behavior.**

The design of the safe/unsafe split means that there is an asymmetric trust
relationship between Safe and Unsafe Rust. Safe Rust inherently has to
trust that any Unsafe Rust it touches has been written correctly.
On the other hand, Unsafe Rust cannot trust Safe Rust without care.
On the other hand, Unsafe Rust cannot trust Safe Rust without care. It can
trust Safe Rust it is a client of, but it cannot trust Safe Rust chosen or
supplied by its clients.

As an example, Rust has the [`PartialOrd`] and [`Ord`] traits to differentiate
between types which can "just" be compared, and those that provide a "total"
Expand Down Expand Up @@ -91,8 +93,13 @@ can be weighed against the benefit. In this case there's basically zero risk;
if integers and slices are broken, *everyone* is broken. Also, they're maintained
by the same people who maintain `BTreeMap`, so it's easy to keep tabs on them.

On the other hand, `BTreeMap`'s key type is generic. Trusting its `Ord` implementation
means trusting every `Ord` implementation in the past, present, and future.
The same can be true across crate boundaries. Say crate `foo` depends on crate
`bar`, then Unsafe Rust in crate `foo` may trust Safe Rust in crate `bar`. This
is because crate `foo` chose to depend on crate `bar`, and by doing so trusted
crate `bar` to be implemented correctly.

On the other hand, `BTreeMap`'s key type is generic. Trusting its `Ord`
implementation means trusting the `Ord` implementation of arbitrary clients.
Here the risk is high: someone somewhere is going to make a mistake and mess up
their `Ord` implementation, or even just straight up lie about providing a total
ordering because "it seems to work". When that happens, `BTreeMap` needs to be
Expand Down
Loading