[rust-dev] The new format!

2013-10-01 Thread Oren Ben-Kiki
I just transitioned my code to use the new format! macros. I was happy to get rid of all the .to_str() I had all over the place, but this turned out not quite as I had expected. I was hoping I'd be able to simply base on the ToStr trait to print anything with {:s}. It turns out that actually

Re: [rust-dev] The new format!

2013-10-01 Thread Huon Wilson
On 01/10/13 16:13, Oren Ben-Kiki wrote: This problem is unique to the String trait. All the other traits (Bool, Pointer, ...) just allow specifying the trait directly without getting too clever with string slices. So... I cheated and added a LowerHex instance my types instead of String

Re: [rust-dev] The new format!

2013-10-01 Thread Oren Ben-Kiki
Ah, so simple. I missed it because it is not listed in the formatting traits list in the documentation. This would solve half my problem - I'd no longer need to use {:x} but use the simpler {}, which is great. Thanks! But it wouldn't solve the problem for printing enums, though. I guess I'd

Re: [rust-dev] The new format!

2013-10-01 Thread Alex Crichton
Huon's suggestion of using fmt::Default is what I would suggest as well. The behavior you're running into is actually a known feature of rust today. You'll find in the fmt module implT: Str String for T, and because of this the compiler will not allow you to implement String for any type

Re: [rust-dev] The new format!

2013-10-01 Thread Oren Ben-Kiki
Perhaps if the type system was smart enough to provide a default implementation of the Default trait for everything that had the ToStr trait, and allowing overrides for specific types? I know that currently this sort of inference is not supported, but it is intended that it would be possible in

Re: [rust-dev] The new format!

2013-10-01 Thread Huon Wilson
On 01/10/13 16:26, Oren Ben-Kiki wrote: Perhaps if the type system was smart enough to provide a default implementation of the Default trait for everything that had the ToStr trait, and allowing overrides for specific types? I know that currently this sort of inference is not supported, but

Re: [rust-dev] The new format!

2013-10-01 Thread Oren Ben-Kiki
Yes, both suggestions sound very reasonable. It would also eliminate the need for the Str trait altogether (since the Default fmt function would avoid the allocation). So there would really be no need for most format specifiers, except stuff like controlling the base of integers, etc. On Tue,

Re: [rust-dev] The new format!

2013-10-01 Thread Paul Colomiets
Hi, On Tue, Oct 1, 2013 at 9:13 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: I know, this is pretty horrible... what is the right thing here? Using {:s} and keep calling .to_str() everywhere? Not sure if that helps. But in python there are conversion specifiers {!s} and {!r} which convert to