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.
As an example, Rust has the
PartialOrdandOrdtraits to differentiate between types which can "just" be compared, and those that provide a "total" ordering (which basically means that comparison behaves reasonably).
BTreeMapdoesn't really make sense for partially-ordered types, and so it requires that its keys implementOrd. However,BTreeMaphas Unsafe Rust code inside of its implementation. Because it would be unacceptable for a sloppyOrdimplementation (which is Safe to write) to cause Undefined Behavior, the Unsafe code in BTreeMap must be written to be robust againstOrdimplementations which aren't actually total — even though that's the whole point of requiringOrd.
From the very first page of the Rustonomicon, itself cited by Gankra in PR#3197 Clarify that RFC1520 does not permit the compiler to replace calls to Clone::clone with a memcpy.