Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Custom polymorphic logging #2366

catamorphism opened this Issue · 8 comments

7 participants


The example I have in mind is:

#debug("%s", ty_to_str(tcx, t));

where t: ty::t. It would be great if I could write:

#debug("%?", tcx, t);

and not have to write out the call to ty_to_str. perhaps there could be an RTS hook to say "for type ty::t, call ty_to_str? I guess this could potentially be very hard since at runtime, tys probably aren't distinguished from ints. Alternately, (though not quite as awesomely), there could be another format string specifier or something for types. Basically, I just want to be able to pretty-print a type in a #fmt call without writing out ty_to_str, because that's a lot of characters :-) (And slightly more seriously, then I have to import ty_to_str, which requires remembering what module it lives in...)


I think we should not have smarter polymorphic logging but rather a to_str interface that various types can implement. Then you should be able to do #debug["%s", val] for any value that has a to_str() method defined.

Types could make use of this if we embedded a back pointer to the tck in the type box.


FWIW there is already a to_str iface in core::to_str.

On a slightly related note I consider that it might be nice if the + operator on strings called .to_str() on its arguments, like in Java/Javascript, because it makes code like "the value of x is " + uint::str(x) a bit more concise.


Not quite done yet: making %s work for anything that implements to_str would be a great enhancement.


This may get fixed by the new logging system in #3309 which is already nominated for a maturity milestone.

I do think whatever we end up with should support to_str(), so nominating this for production ready.


Just a note: in the compiler itself, for now, I suggest writing debug!("%s", foo.repr(tcx)). I added the repr trait and implemented it for many common types. If you find it doesn't work, add an impl for your own favorite type.


accepted for backwards-compatible milestone

@brson brson referenced this issue

Redesign the logging subsystem #3309

10 of 13 tasks complete

@catamorphism, would you consider this closed with the new formatting traits of format!? Now, any type which implements the corresponding trait can be formatted with that character.


I think we consider this fixed now, although we still need to migrate away from the old formatting.

@thestinger thestinger closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.