add Formatter::debug

[Centril]

Adds (to std::fmt::Formatter):

fndebug<D:Debug>(&mutself,d:D) -> Result{
<DasDebug>::fmt(&d,self)}

which is intended to aid in Debug impls and read better than D::fmt(&d, fmt).

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[Centril]

r? @sfackler

[kennytm]

In the example, why not simply use write!(formatter, "{:?} => {:?}", self.0, self.1)...?

[Centril]

Per discussion with @kennytm on #rust-libs I updated the example to one where you can't use the above snippet (since there's a diff btw {:?} and {:#?}).

[ollie27]

Why only for Debug? Why is it taking it's argument by value when it only uses a reference?

[sfackler]

If we had done the fmt traits "right" their method names would match the type names rather than all being fmt so this wouldn't be a problem. How about adding those methods to the fmt traits instead?

pubtraitDisplay{fnfmt(&self,fmt:&mut fmt::Formatter) -> fmt::Result;fndisplay(&self,fmt:&mut fmt::Formatter) -> fmt::Result{self.fmt(fmt)}}

[kennytm]

@sfackler This will cause new methods named .display()/.debug() etc appear on types impl/deriveing the format traits, which may not be a good idea (even if they aren't visible when not useing the trait).

[sfackler]

Adding new methods to a trait will cause new methods to appear, yeah. This would not be the first time we've added methods to a trait. We'd want to run crater to see if there's a surprising amount of breakage like we did for e.g. Ord::min.

[kennytm]

Sure, but these are not like super useful method that would be commonly used, so I prefer not to take the risk here :D

[Centril]

Hmm; while I agree on @sfackler's point that .debug(..) rather than .fmt(..) would have been appropriate, that was not the main goal... The main goal for me was that you often use fmt.xyz() and then all of a sudden the polarity is reversed, which reads poorly. So fmt.foo() uniformly reads better.
Obviously this is not an important addition, but kinda nice?

@ollie27 I can change to include & if we think that's best.

[bors]

☔ The latest upstream changes (presumably #48978) made this pull request unmergeable. Please resolve the merge conflicts.

[shepmaster]

It's unclear to me where this PR stands. @Centril, do you believe you've addressed all the feedback from @sfackler?

[Centril]

@Centril, do you believe you've addressed all the feedback from @sfackler?

That's not for me to decide; but I think @sfackler suggested addition tries to solve a different issue, that .fmt(..) on Debug and Display conflict. But inside a Debug implementation, the addition of fmt.debug(..) is intended mainly for decreasing asymmetry of reversing the positions of fmt and the thing being formatted. Of course, we could decide that the asymmetry is not a problem, and so close this PR -- which I'm entirely fine with. I leave it up to you to decide whether this is a problem that needs solving =)

[sfackler]

The asymmetry is with debug_struct, etc? I don't really see that as an issue honestly. It seems pretty natural to want to delegate the call to one of your fields like you would hash or whatever.

[Centril]

@sfackler

The asymmetry is with debug_struct, etc?

Indeed it is.

I don't really see that as an issue honestly.

Personally, it bugs me a bit, but not much. Shall I close the PR then?

[sfackler]

Yeah I'd lean towards closing.

[Centril]

Alright, closing then =)