Reading notes: dyn* doesn't need to be special

tags: reading-club

dyn* doesn't need to be special

Attendees: tmandry, eholk

Questions / Observations

• Seems motivated by storages API

Relation to dyn*

The good

• Maybe we can do dyn* as a library (though this post doesn't quite show that)
• &move using Box<T, &mut MaybeUninit<T>>
  • Means Box becomes the universal way of saying "I own the value referred to by this handle"
    • where handle may embed the value directly, or be a pointer to it
  • Continuing down that path: if I have a T I could turn it into Box<T, TransparentStorage<T>>
    • Has same memory layout as T
  • Not just Box, Rc and Arc become the universal way of saying I have a shared refcounted object
    • Because storages API lets you abstract over all implementations of that
  • Core argument on internals: is dyn* Trait + Clone good enough to represent Arc<dyn Trait>?
    • Does clone clone the Arc or the thing in the Arc?
    • Could add new traits like CloneByValue
      • ..comes down to whether you have UnsafeCell in your type.. we could auto-derive this somehow…

The bad

• "dyn* needs to be DerefMut": Not necessarily. Pin would be "hidden" by the dyn*
  • dyn* Trait where Trait has self: Pin<..> methods means that "the pointer behind dyn* is pinned"
    • More formally: that the type that was turned into dyn* is Unpin
    • Enforced at creation of dyn*
    • Example: <dyn*>::from(Box::pin(whatever))
      • Pin<Box<T>>: Unpin
  • Corollary: There are "trait views": dyn* &Trait means you implement only &self methods

Trait views

General dyn*, etc.

• not true: &dyn Trait: Trait
• true: dyn* Trait: Trait
  • Can fake this by having dyn* Trait: Deref<dyn Trait>
  • Can't do: forall trait Trait: impl<T> Trait for Dyn<T> where T: Trait
    • (if we tried to do dyn* in a library)