Display and FromStr are about going to / coming from the "one obvious string representation," and that implies that they use the same string representation.
The unfortunate reality is that most things don't have one canonical string representation. So unless you're writing a type that does, my recommendation is still to not implement Display or FromStr (unless it is an Error).
"Turn it into a string" has many possible use cases and interpretations, and unfortunately they get muddled up in whatever standard "to string" facilities are provided. Rust does a lot better than a lot of languages here, by providing both "to string for debugging" and "to string for display". But there's still a lot of leeway (in both of them), thus having this discussion at all.
It's hard to say what the "correct" design for display string construction really is. Especially since in a robust application, most are going to be de/serialization to a machine-readable format, or run through a localization system, and a simple "make it a string" API fits neither of those.
I think the only really solid and well-intuition-portable Display implementations are
-
Display + Error: display is how you display the error to "the appropriate audience" for that error -
Display + FromStr: both use the same canonical (locale invariant) string representation - `.method(...) -> impl Display": display adapter for a complex type, read the method docs
- An actual text or string type
- (any other type who's sole/primary purpose is to be stuck into a
Writeoutput stream)
If your type is Display and doesn't fit one of these categories, you're running a risk of expectation mismatch, especially if you don't document what your Display implementation is. And if you do, changing the documented contract is clearly breaking.