Currently we have two kinds of formatting traits: std::fmt::Show
and its friends, and debug::fmt::Poly
. The former traits intend to be used for generic stringification, and the latter trait intends to be used for debugging.
Unfortunately, debug::fmt::Poly
is currently not very usable as many have pointed out. For example, println!("{:?}", vec![3u, 4, 5])
gives collections::vec::Vec<uint>{len: 3u, cap: 4u, ptr: (0x7ff94bc0f040 as *mut ())}
, which is clearly not what one wants. It follows that the debugging information is best left to the type itself; the current Poly
exposes the implementation details, which the end user should not concern about.
As the first attempt (pre-pre-RFC), I’d like to propose two suggestions connected to each other:
-
Make a separate trait for inspection. I think Ruby-esque
Inspect::inspect
is fine (Python hasrepr
, butRepr
is already used in some (obscure) cases from stdlib). It can be either instd
ordebug
(TBD). There would be#[deriving(Inspect)]
which does the same as#[deriving(Show)]
. (I think there was a concern about having#[deriving(Show)]
itself, so it might be simply renamed in that case.) Otherwise it should be same toShow::fmt
; one can also think about the pretty-formatting, but that would be another story (we don’t have a stdlib-agreed way to do the pretty printing after all). -
Make
TyDesc
contain a glue to eitherShow::fmt
orInspect::inspect
. This way{:?}
can continue to be used for structural inspection (henceforth relieving the burden of implementingShow
orInspect
for every type) but can switch toInspect
whenever appropriate. This affects the binary size, so it should be made optional or dependent to the use ofdebug
crate (by defining a relevant lang item indebug
, for example) or so.