On Fri Jul 4, 2025 at 12:41 AM CEST, Tamir Duberstein wrote:

On Thu, Jul 3, 2025 at 4:36 PM Benno Lossin [off-list ref] wrote:

quoted

On Thu Jul 3, 2025 at 8:55 PM CEST, Tamir Duberstein wrote:

quoted

On Thu, Jul 3, 2025 at 11:08 AM Benno Lossin [off-list ref] wrote:

quoted

On Thu Jul 3, 2025 at 3:55 PM CEST, Tamir Duberstein wrote:

quoted

On Thu, Jul 3, 2025 at 5:32 AM Benno Lossin [off-list ref] wrote:

quoted

On Tue Jul 1, 2025 at 6:49 PM CEST, Tamir Duberstein wrote:

quoted

+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