reorder things to be hopefully less confusing

Author: RalfJung

library/std/src/keyword_docs.rs

@@ -2145,14 +2145,14 @@ mod type_keyword {}
 /// contract of `idx_unchecked`. Implementing `Indexable` is safe because when writing
 /// `idx_unchecked`, we don't have to worry: our *callers* need to discharge a proof obligation
 /// (like `use_indexable` does), but the *implementation* of `get_unchecked` has no proof obligation
-/// to contend with. Note that unlike normal `unsafe fn`, an `unsafe fn` in a trait implementation
-/// does not get to just pick an arbitrary safety contract! It *has* to use the safety contract
-/// defined by the trait (or one with weaker preconditions).
-///
-/// Of course, the implementation may choose to call other unsafe operations, and then it needs an
-/// `unsafe` *block* to indicate it discharged the proof obligations of its callees. For
-/// that purpose it can make use of the contract that all its callers must uphold -- the fact that
-/// `idx < LEN`.
+/// to contend with. Of course, the implementation may choose to call other unsafe operations, and
+/// then it needs an `unsafe` *block* to indicate it discharged the proof obligations of its
+/// callees. For that purpose it can make use of the contract that all its callers must uphold --
+/// the fact that `idx < LEN`.
+///
+/// Note that unlike normal `unsafe fn`, an `unsafe fn` in a trait implementation does not get to
+/// just pick an arbitrary safety contract! It *has* to use the safety contract defined by the trait
+/// (or one with weaker preconditions).
 ///
 /// Formally speaking, an `unsafe fn` in a trait is a function with *preconditions* that go beyond
 /// those encoded by the argument types (such as `idx < LEN`), whereas an `unsafe trait` can declare