There has been a long-running debate about
Show which we need to resolve in settling basic API guidelines.
On the one hand, to be able to use
#[deriving(Show)] (a very convenient feature) it is crucial that essentially all types implement the
On the other hand, anything implementing
Show automatically gets a
to_string method. In certain cases, this makes it problematic to implement
Show. For example,
Path is not necessarily unicode, and so can only be converted to a string in a lossy fashion. For this reason,
Path has not implemented
Show directly, but instead has a
display adapter (which does implement
Show), forcing users to acknowledge the lossyness.
Unfortunately, this means that structures with
Path fields cannot use
#[deriving(Show)], which is quite painful.
So the questions are:
- What expectations should we have for a
Showimplementation? When is lossyness acceptable, if ever?
to_stringbe coupled with
In particular, you could imagine having multiple
Show-like traits, some for debugging (where lossyness is allowed) and some for more “formal” string conversions. Anything implementing the more “formal” string conversion could automatically implement the debugging version (via a blanket impl), and both could support deriving.
But this seems like a fair amount of engineering around a very core concept. A simpler alternative would be to say that
Show is intended for lightweight string conversions, primarily for debugging, and may be lossy.
Some of the tradeoffs are discussed in this github thread.
I was intending to write up an RFC on this topic, but before I do so, I wanted to solicit general feedback from the community, to see which way people lean, and perhaps to discover some new alternative designs.
(Note that Java has similar issues, since every object implements
toString there. See this page for some discussion/guidelines.)