diff options
| -rw-r--r-- | library/core/src/str/traits.rs | 11 |
1 files changed, 5 insertions, 6 deletions
diff --git a/library/core/src/str/traits.rs b/library/core/src/str/traits.rs index 2f425c82dc8..b9559c83171 100644 --- a/library/core/src/str/traits.rs +++ b/library/core/src/str/traits.rs @@ -756,20 +756,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 /// |