Tracking issue for dyn-star

[eholk]

This issue tracks known issues or missing functionality with support for dyn* Trait objects. These are an experimental feature that are meant to support async function in dyn traits.

In addition to the issues linked here, you can also find things that need to be done by greping the code for // FIXME(dyn-star) or looking at the F-dyn_star label.

• dyn* ICE primitive read not possible for type: [i32; 4] #102173
• &dyn* causes an ICE #102172
• Broken LLVM function when pushing dyn* item to Vec. #102141
• Boxes can not be cast to dyn* #102427
• ICE involving references to dyn* #102429
• Bad MIR when casting a reference to dyn* #102430
• rustfmt eats dyn_star syntax rustfmt#5542
• dyn* does not support trait upcasting #104800
• dyn and dyn* should (probably?) have their TyKind representation split from one another -- Create a new TyKind::DynStar variant #107908 was an attempt at this

Associated PRs

• Initial implementation of dyn* #101212
• (list is incomplete)

About this issue

This is a lang-team experiment -- there hasn't been an RFC for this functionality, we're exploring it both as a potential implementation detail and (more speculatively) a possible language feature in the future. You can read more about dyn* at this blog post.

Lang-team champion: @nikomatsakis

[Rageking8]

@rustbot label +C-tracking-issue

[RalfJung]

Currently the dynamic type hidden by dyn* is required to match usize in size and alignment. In principle it seems possible to allow smaller alignment, and possibly even smaller size (though in the latter case care has to be taken that the vtable always ends up at the same offset -- this would be easier if the vtable was the first component of the pair, not the 2nd). Are there plans to allow that?

[ds84182]

Right now you can actually place smaller size & align types with dyn* by stuffing it inside a usize with a little bit of unsafe. Due to the existing alignment requirements for the vtable ptr, it will always end up at the same offset as long as size_of::<T>() <= size_of::<usize>() && align_of::<T>() <= align_of::<usize>().

[RalfJung]

Due to the existing alignment requirements for the vtable ptr, it will always end up at the same offset as long as size_of::() <= size_of::() && align_of::() <= align_of::().

This is not true for size_of::<T>() == 0. Also, this assumes that for a usize (and pointers), size == align.

[ds84182]

This is not true for size_of::<T>() == 0. Also, this assumes that for a usize (and pointers), size == align.

Ah, right. I guess a better way to describe the requirements is something like

union DynStarCompatible<T> {
  true_value: T,
  size_align: usize,
}

where DynStarCompatible<T> matches the size and align of usize. (of course, this still has the same assumption about usize and ptrs, but this could be trivially replaced with *const ())

[eholk]

Currently the dynamic type hidden by dyn* is required to match usize in size and alignment. In principle it seems possible to allow smaller alignment, and possibly even smaller size (though in the latter case care has to be taken that the vtable always ends up at the same offset -- this would be easier if the vtable was the first component of the pair, not the 2nd). Are there plans to allow that?

Yes, this is something I would like to support.

[RalfJung]

From the initial PR:

Note that this is never intended to become stable surface syntax for Rust, but rather dyn* is planned to be used as an implementation detail for async functions in dyn traits.

Honestly that seems like a shame -- this could be useful way beyond async fn I think. (But then there are other proposals that are even more general so indeed stabilizing this particular one might be the wrong call.)

[l-Luna]

From the initial PR:

Note that this is never intended to become stable surface syntax for Rust, but rather dyn* is planned to be used as an implementation detail for async functions in dyn traits.

Honestly that seems like a shame -- this could be useful way beyond async fn I think. (But then there are other proposals that are even more general so indeed stabilizing this particular one might be the wrong call.)

might be useful to point out that the post you linked intentionally ignores any non-Box types, considering them not useful for supporting Pin

[eholk]

From the initial PR:

Note that this is never intended to become stable surface syntax for Rust, but rather dyn* is planned to be used as an implementation detail for async functions in dyn traits.

Honestly that seems like a shame -- this could be useful way beyond async fn I think. (But then there are other proposals that are even more general so indeed stabilizing this particular one might be the wrong call.)

Maybe "never" was too strong in the original PR. I think dyn* will likely turn out to be a more ergonomic version of dyn, so hopefully we can find a version that makes sense to make part of the surface language at some point. I think the point was we picked dyn* as a placeholder syntax that we didn't want to bikeshed just yet, and if the feature becomes part of Rust proper we'd probably do it under a different syntax.

[oxalica]

I doubt that if this needs to be a language feature instead of a library impl.
We can implement dyn* using ptr_metadata:

// Or `Dyn: Pointee + ?Sized`, but we'll tolerant non `dyn` unsized types. 
pub struct InlinedDyn<Dyn: Pointee<Metadata = ptr::DynMetadata<Dyn>> + ?Sized> {
    data: usize, // Or anything if you like, or even with a const generic size.
    metadata: ptr::DynMetadata<Dyn>,
    _marker: PhantomData<Dyn>,
}
impl<Dyn: Pointee<Metadata = ptr::DynMetadata<Dyn>> + ?Sized> InlinedDyn<Dyn> {
    pub fn new<T: Unsize<Dyn>>(value: T) -> Self;
}
impl<Dyn: Pointee<Metadata = ptr::DynMetadata<Dyn>> + ?Sized> ops::Deref for InlinedDyn<Dyn> {
    type Target = Dyn;
}
impl<Dyn: Pointee<Metadata = ptr::DynMetadata<Dyn>> + ?Sized> ops::DerefMut for InlinedDyn<Dyn> {}

Is there any feature I missed that cannot be implemented like this?

[bjorn3]

That doesn't allow coercing to dyn* or using it as receiver. It also doesn't allow an automatic impl Trait for dyn* Trait for every trait.

[compiler-errors]

Noting here (and left an unchecked checkbox above) that dyn and dyn* should (probably?) have their TyKind representation split from one another. #107908 was an attempt at this, but the PR got stale, and rebasing it would've probably been a pain.

[oxalica]

That doesn't allow coercing to dyn* or using it as receiver.

That's fair, but I still think a struct-like lang-item is more pretty, just like Box<T>. So we can more easily extend it with more methods or parameterized it with const-generic custom size or alignment.

It also doesn't allow an automatic impl Trait for dyn* Trait for every trait.

Is this really necessary? Box<T> doesn't do this also, but we are still able do make Box<dyn FnOnce()> work.

[bjorn3]

Box<T> doesn't do this also, but we are still able do make Box<dyn FnOnce()> work.

Through an unstable feature to allow unsized arguments that is. Not something that can be replicated by end users for other traits.

[eholk]

That doesn't allow coercing to dyn* or using it as receiver.

That's fair, but I still think a struct-like lang-item is more pretty, just like Box<T>. So we can more easily extend it with more methods or parameterized it with const-generic custom size or alignment.

For what it's worth, we consider dyn* to be a placeholder syntax while we develop the idea. If we were to stabilize something like as part of user-facing Rust, we'd probably spell it something like Dyn<T> instead.

[RalfJung]

dyn and dyn* should (probably?) have their TyKind representation split from one another

#115699 on the side fixes yet another bug caused by those two being the same TyKind.