> On 21 Feb 2026, at 10:40, Alice Ryhl <[email protected]> wrote: > > On Sat, Feb 21, 2026 at 09:44:45AM -0300, Daniel Almeida wrote: >> >> >>>> On 21 Feb 2026, at 08:17, Alice Ryhl <[email protected]> wrote: >>> >>> On Thu, Feb 12, 2026 at 11:11:13AM +0100, Boris Brezillon wrote: >>>>> +type LockedSeat<T, const MAX_SLOTS: usize> = LockedBy<Seat, >>>>> SlotManager<T, MAX_SLOTS>>; >>>>> + >>>>> +impl<T: SlotOperations, const MAX_SLOTS: usize> Unpin for SlotManager<T, >>>>> MAX_SLOTS> {} >>>> >>>> Do we really need to explicitly flag this type Unpin? I thought this >>>> was the default if the struct is not pinned (and it's not AFAICT). >>> >>> It may be cleaner to add `#[pin_data]` to the struct and rely on the >>> Unpin impl it generates. >>> >>> In general, the default Unpin implementation is to inherit from the >>> fields. When you add #[pin_data], it's changed to only inherit from >>> fields marked #[pin]. By adding #[pin_data] but not marking any fields >>> #[pin], it will be Unpin unless any of the zero fields marked #[pin] are >>> Unpin, i.e. it will always be Unpin. >> >> Why do we need this if all fields are Unpin? > > Its fields are not necessarily Unpin. 'manager' could be any type, > including !Unpin types. > > Adding #[pin_data] without marking any fields #[pin] is equivalent to > the explicit impl Unpin the patch has now.
If the T or the slot data is !Unpin, then the SlotManager is !Unpin and that’s fine. This has been my point from the beginning. I don’t see why we need to deviate from this default behavior. This is much clearer than deriving pin_data with 0 #[pin] fields. > >>>>> + // FIXME: Annoying manual copy. The original idea was to not add >>>>> Copy+Clone to SeatInfo, >>>>> + // so that only slot.rs can change the seat state, but there >>>>> might be better solutions >>>>> + // to prevent that. >>>> >>>> Okay, I guess we want some inputs from Daniel and/or Alice on that one. >>> >>> You could consider only implementing Clone. That way, copies do not >>> happen unless you do so explicitly. Or add a private method on the type >>> that has the same function as Clone if you do not wish to expose it. >> >> Please check my solution where clone is not needed. > > If you do not need to return it from the function, then that's fine too, > of course. > > Alice
