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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
