FromStr: Rework explanation of FromStr/Display round-tripping

- Drop the phrasing "usually a mistake".
- Mention that `Display` may not be lossless.
- Drop a misplaced parenthetical about round-tripping that didn't fit
  the paragraph it was in.

Author: joshtriplett

library/core/src/str/traits.rs

@@ -752,20 +752,19 @@ unsafe impl SliceIndex<str> for ops::RangeToInclusive<usize> {
 /// parse an `i32` with `FromStr`, but not a `&i32`. You can parse a struct that
 /// contains an `i32`, but not one that contains an `&i32`.
 ///
-/// # Input format
+/// # Input format and round-tripping
 ///
 /// The input format expected by a type's `FromStr` implementation depends on the type. Check the
 /// type's documentation for the input formats it knows how to parse. Note that the input format of
 /// a type's `FromStr` implementation might not necessarily accept the output format of its
-/// `Display` implementation; thus, calling `.parse()` on the output from `Display` is usually a
-/// mistake, unless the type has provided and documented additional guarantees about its `Display`
-/// and `FromStr` implementations.
+/// `Display` implementation, and even if it does, the `Display` implementation may not be lossless
+/// so the round-trip may lose information.
 ///
-/// If a type happens to have a lossless `Display` implementation whose output is meant to be
+/// However, if a type has a lossless `Display` implementation whose output is meant to be
 /// conveniently machine-parseable and not just meant for human consumption, then the type may wish
 /// to accept the same format in `FromStr`, and document that usage. Having both `Display` and
 /// `FromStr` implementations where the result of `Display` cannot be parsed with `FromStr` may
-/// surprise users. (However, the result of such parsing may not have the same value as the input.)
+/// surprise users.
 ///
 /// # Examples
 ///