When should I implement Display for my library structs?

If I look at the documentation for std::time::Duration, it says:

Duration intentionally does not have a Display impl, as there are a variety of ways to format spans of time for human readability

Saying that "there are a variety of ways to format spans of time for human readability" is true, but it also applies to almost every other context, not just spans of time. This makes me wonder whether libraries should implement Display at all and whether Display is actually meant to be implemented by bin crates only, which are closer to the end user and therefore know what format to use exactly.

Is there any guideline around Display, when it should be avoided and how to deal with multiple possible formats?

I suppose the main argument here is that there are multiple equally valid/common ways of displaying durations of time. This seems similar to why &str or String can’t be used as an Iterator directly: There are multiple equally valid way to iterate a string, either by bytes or by unicode scalar values (“by chars”) or by something longer, e.g. as provided by unicode_segmentation - Rust, you’ll have to call .bytes() or .chars() explicitly to choose which one you want. Similarly, to display a Duration, you can choose implementations from other crates, e.g. you can use human_time::format_duration.

If there’s one way to Display your type that’s clearly “the best” or “the most common” or even “the only reasonable approach”, then you should use that.

Another important thing for consideration when implementing Display is that it entails a ToString implementation. So your type will automatically get a to_string method; you should make sure that this method name is not completely confusing. This method is a good indicator that String’s implementation of Display should display the String verbatim with out quotes or escapes (and that’s what it does). This is also why things like OsString or Path (and their counterparts OsStr, PathBuf) don’t implement Display. They have their own to_str or into_string methods or similar, all of which are fallible or lossy. So if you don’t want an infallible conversion method called “to_string”, don’t implement Display. E.g. Path even has a method called .display(), because there arguably is a reasonably “most common / best” way to display a Path.

1 Like

If I think about floating point numbers, there are two main display possibilites: comma or point as decimal separator.
But in many situations, both choices are ok - the user will be able to understand both.

But with date and time,. I'm always confused. So I prefer that rust has no default choice and I must think about my current use case.

A weak heuristic: If you're not going to bother making a FromStr too, just skip Display.

I think for most types it's best to just not have Display. People can format the various parts as they want.

Debug and serde support are the important ones, most of the time.


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.