Pre-eRFC: Let's fix DSTs

language design
2

For reference, I’ve got a custom RFC draft at https://github.com/kennytm/rfcs/tree/dyn-type/text/0000-dyn-type, but far from complete even for Pre-RFC. I believe there should a dedicated syntax for declaring custom DST instead of simply impl Referent for T.

Some opinions on this Pre-RFC from what I’ve learned there:

  1. DynAligned doesn’t work. The minimal promise a type can give about alignment, if any, is AlignFromMeta. This is because in a DST struct

    struct X<T: DynAligned> {
    a: u8,
    b: T,
}

    if you need to read &x.b, you’ll first need to find the offset of b, which in turn requires knowing the alignment of b without knowing its pointer value.

    Even if DynAligned is more flexible, I don’t think any types need such flexibility, or can do anything useful with it. So I’d recommend reducing the hierarchy to 5 traits (remove DynAligned and collapse AlignFromMeta into DynSized):

    Referent                                   (extern type)
DynSized:      Referent      (just a super trait for SizeFromMeta and Aligned)
SizeFromMeta:  DynSized                    (dyn Trait)
Aligned:       DynSized                    (CStr, Thin)
Sized:         Aligned + SizeFromMeta      (u8, u16)

  2. Deprecating ?Sized in favor of a white-list of special traits is interesting. As you mentioned, I have some worry about the interaction with Move though. Would this mean T: Sized becomes T: Sized + ?Move? Wouldn’t it break backward compatibility?

    An alternative idea is to make ? means ?Sized — T: DynSized + ?. The + ? looks very cryptic, but is still better than the Sized + ?Sized nonsense (this means ?Move).

5 Likes