Edit: Maybe instead of having two traits DynMove: DynSized
and Move: DynMove + Sized
, there could be a single trait Move: DynSized
. Pro: One less trait to worry about. Con: The fully explicit bound that used to be T: Move
becomes T: Move + Sized
. This only really affects traits, and it would still be equivalent to T: Sized
, but it means you need two (usually implicit) bounds to be able to statically move something.
One way to reconcile the two worlds:
- Split
DynSized
intoDynSized
andDynMove: DynSized
, with every aspect of theDynSized
proposal replicated for each. UseDynSized
to constrainsize_of_val
, and useDynMove
pretty much everywhere else. Immovable types become!DynMove
. - Introduce
Move: DynMove + Sized
. -
Sized
remains a default bound.Move
is a default bound for allT
whereT: Sized
(explicitly or by default), includingSelf
. This is so that an explicitSelf: Sized
bound impliesSelf: Move
(otherwise most code that does this would break). -
?Sized
removes theMove
default bound as well, which follows from the previous point. This means that immovable types work with all existing?Sized
type parameters, and most code using immovable types will continue to use a?Sized
bound. - Anything other than
Self
that wants to work specifically with sized but potentially immovable types can switch to?Move
, which is not compatible with?Sized
callers, requiring migration anywhere this applies. - To have a sized but potentially immovable
Self
, you needSelf: ?Move + Sized
. This follows the pattern ofSelf
needing to beSelf: [constraints] + Sized
in order to have the same constraints as another type parameterT: [constraints]
.
Pro: Sized
and Move
are retained as distinct properties.
Con: Sized
implying Move
by default in traits is a bit weird… and we were worried about the original proposal being hackish . This could at least be mitigated by adding a warning recommending these instances migrate to having explicit Move
/?Move+Sized
bounds instead, at the cost of increasing the encouraged migration footprint.
Re whether this is on topic: yeah, oops. Though, technically, the topic is about Pin
owning the pinned value. One way would be with &move
and PinMove
, and another would be with !Move
and Pinned
, so…