Unlike all previous attempts which requires user to provide size_of_val and align_of_val, I think this approach is more suitable for Rust, since

it automatically handles Drop

it automatically handles Send and Sync

it needs less unsafe

Also, from the experience of impl Trait for .. ↦ auto trait Trait, I don’t think separating the metadata of the DST into an impl block is a good idea (only japaric’s draft attach the metadata to the type, every other proposal so far provides the metadata as an associated type of a Referent/DynSized trait ).

How would this work for a type like CStr, where (unless I’m horribly mistaken) the length is not contained in the metadata but instead has to be computed by following the data pointer and then searching for the null terminator?

This seems like a much more unnecessarily complex proposal, and I feel as though it doesn’t fix as many problems as the proposal I put forward. I don’t agree with this direction at all - the lack of DynSized is a major issue, in my very strong opinion - panicking in size_of_val and align_of_val is a really, really bad choice. It also is not a very minimal proposal, introducing unnecessary complexity in Aligned, imo.

The main reason Aligned is introduced is because of field offset in DST structs, and you’ll need to handle this issue if you want to support Thin<dyn Trait>. I see this as an essential complexity to prevent accidental unsafety.

@kennytm I disagree strongly that this machinery is necessary. I’m strongly of the opinion that the RFC I’ve put forward is both simpler, and easier to use, especially for the kind of Rust programmer who is likely to write the kind of code that requires this.