Can `Pin` own its referent instead of borrowing mutably?

language design
41

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 into DynSized and DynMove: DynSized, with every aspect of the DynSized proposal replicated for each. Use DynSized to constrain size_of_val, and use DynMove pretty much everywhere else. Immovable types become !DynMove.
  • Introduce Move: DynMove + Sized.
  • Sized remains a default bound. Move is a default bound for all T where T: Sized (explicitly or by default), including Self. This is so that an explicit Self: Sized bound implies Self: Move (otherwise most code that does this would break).
  • ?Sized removes the Move 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 need Self: ?Move + Sized. This follows the pattern of Self needing to be Self: [constraints] + Sized in order to have the same constraints as another type parameter T: [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 :smile:. 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… :wink:

1 Like