On Fri Jul 4, 2025 at 12:41 AM CEST, Tamir Duberstein wrote:
On Thu, Jul 3, 2025 at 4:36 PM Benno Lossin lossin@kernel.org wrote:
On Thu Jul 3, 2025 at 8:55 PM CEST, Tamir Duberstein wrote:
On Thu, Jul 3, 2025 at 11:08 AM Benno Lossin lossin@kernel.org wrote:
On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote:
On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin lossin@kernel.org wrote:
On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote: > +impl<T: ?Sized + Display> fmt::Display for Adapter<&T> { > + fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { > + let Self(t) = self; > + Display::fmt(t, f)
Why not `Display::fmt(&self.0, f)`?
I like destructuring because it shows me that there's only one field. With `self.0` I don't see that.
And what is the benefit here?
In general the benefit is that the method does not ignore some portion of `Self`. A method that uses `self.0` would not provoke a compiler error in case another field is added, while this form would.
Yeah, but why would that change happen here? And even if it got another field, why would that invalidate the impl of `fn fmt`?
I don't know, but I would rather force a person to make that decision when they add another field rather than assume that such an addition wouldn't require changes here.
I don't think so. If this were in another file, then destructuring might make sense if the struct could conceivably get more fields in the future **and** it if the other file relied on there only being one field (or if it *had* to be changed when there was a field added). This isn't the case here so it's just unnecessary noise.
--- Cheers, Benno