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 the future, right?


On Tue, Oct 1, 2013 at 9:24 AM, Oren Ben-Kiki <[email protected]> wrote:

> 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
> still have to litter my code with lots of .to_str() when printing them :-(
>
>
> On Tue, Oct 1, 2013 at 9:12 AM, Huon Wilson <[email protected]> wrote:
>
>> 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 (which conflicts with libstd) or Str (which I can't
>>> implement). I now print my types with {:x} (I think of it as "user eXtended
>>> format").
>>>
>>> I know, this is pretty horrible... what is the "right thing" here? Using
>>> {:s} and keep calling .to_str() everywhere?
>>>
>>>
>> There's std::fmt::Default, which corresponds to having no format
>> specifier (e.g. {} or {:10} or {a}, etc).
>>
>>
>> Huon
>> ______________________________**_________________
>> Rust-dev mailing list
>> [email protected]
>> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>>
>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to