changed 2 years ago
Linked with GitHub

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)
Select a repo