[Pre-RFC]: Unnamed struct types

language design
58

One place I’d like to note that this would be quite useful is in associated types, and another is in defining purely internal field types with less boilerplate. To abuse the classic example of shapes:

struct RectangleClassic {
    width: u64,
    height u64,
    red: u8,
    green: u8,
    blue: u8,
}

struct RectangleTidy {
    dimensions: {
        width: u64,
        height: u64,
    },
    color: {
        red: u8,
        green: u8,
        blue: u8,
    },
}

This occupies a nice point in between writing things out completely flat (RectangleClassic), using classic tuples, and factoring things out into entire types of their own. Unlike RectangleClassic, members with correlated behaviors are kept together. Unlike tuples (but like RectangleClassic), each field has a meaningful name. Unlike creating new nominal types, boilerplate is still kept to a minimum.

in addition, I feel these would provide a valuable midpoint along any eventual refactor from RectangleClassic to distinct types - while tuples would force a garden-path divergence where the developer removes names and then re-adds them, and custom types require #[derive] boilerplate for Copy, Clone, Debug, etc, these types (presuming that, like tuples, those traits are sensibly defaulted) have none of those drawbacks.

9 Likes