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. > >>> + // 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
