Curious, why Debug & Display have use the same fmt method name? I think it could cause problems with ambiguity if you have both traits in scope (IIRC, something similar happened for backtrace crate recently, whe adding a Display impl broke the clients, most notably failure).
Wouldn’t it be better and more idiomatic to have debug and display methods?
I disagree that it is necessary to disambiguate them. All the formatting traits share the same method name, so any proposal could take all of them into account. I’ve found that they always disambiguate in my use by which trait bounds are used on the type they are used on.
Technically you’re not supposed to use those directly, but instead are expected to use write!(f, “{}”, foo) or write!(f, “{:?}”, foo) instead. Both of which should optimize to the respective direct calls, and look more obvious. They also don’t require importing the traits.
Doesn’t write!() hard-code ::std::fmt::Debug and ::std::fmt::Dislay for {:?} and {}, though? If it hardcodes those I don’t think it would be an issue hardcoding different method names.
I personally like the names, though, since they’re descriptive and don’t repeat information from the trait.
I meant that write! macro uses dot call and not UFCS for calling write_fmt on the first argument. This is done to enable “duck typing” and making the same write! macro work with both io::Write and fmt::Write. Calls to Debug/Display indeed can use UFCS.