Conditions for unsafe code to rely on correctness
Rust Internals [Unofficial]
February 11, 2026
ais523:
> It's written in the form of a safety requirement, which it is within the module, but from the point of view of users of the module it's a robustness guarantee ("unsafe code may rely on this guarantee").
This is not exactly an example of safety guarantee. It's an example of safety invariant (which acts as both requirement and guarantee) encoded in the type system with a newtype. What I'm looking for is an example of a function with a safety guarantee in its documentation (i.e. not encoded in the type system).
RalfJung:
> I think the status quo of the ecosystem today is fairly clear: it is generally fine for a crate to rely on documented statements of other crates, including for soundness.
Cool! Is this documented somewhere? If not, where should it go?
RalfJung:
> That sounds like a slightly different question to me and is more of a RUSTSEC policy question.
If it's different, then what does "fine" mean in your previous quoted sentence? I would naively expect the RUSTSEC policy to follow that convention. Or maybe there's simply no hard rule, since you used the word "generally"?
Discussion in the ATmosphere