Pre-RFC: Associated structs, enums, traits On structs, enums, traits

language design
1

Summary

This Pre-RFC is to suggest the allowance of associated structs, enums and traits to be defined in structs, enums and traits.

Movitation

Currently if we have to write a struct which has a property which is another struct, enum or trait, we would have to write the following (the following example uses a struct + enum for demonstration of how we write this currently):

struct SomeStruct {
    property: SomeEnum
}

enum SomeEnum {
    Value1,
    Value2
}

To me it would be better to allow the following along the lines of:

struct SomeStruct {
    property: SomeEnum;

    enum SomeEnum {
        Value1,
        Value2
    }
}

Visibility modifiers can also be applied to the associated structs, enums or traits.

For private associated structs/enums/traits within the types, maybe (?) the following can be added?

  • pub(in struct)
  • pub(in enum)
  • pub(in trait)

Design

This change will require the acceptance of associated structs, enums and traits inside a struct, enum or trait. However, there are some syntax rules I propose about the feature:

  • A semicolon is required to show that the usual declaration of the struct or enum has ended before writing the associated struct, enum or trait;
  • For traits, they can be declared anywhere as long as it is ended with a ;.

Alternatives

Feel free to suggest some alternatives to this (even though I did not come up with any for now)!

Drawbacks

Unresolved questions

2 Likes
2

You'd probably be interested in the structural records RFC. And here's another thread on the topic.

3

I see. The feature you linked to, as for me, only partially satisfies what I wanted.

I am currently proposing nesting structs into structs, enums and traits; or simply nesting "types".

4

P.S. I have edited the Pre-RFC to include a few more details.

5

I just reviewed the structural records RFC and see that it's now in FCP to be closed, alas. In the process they noted that RFC 2102 was accepted, but that's even more limited in scope (FFI with C is the motivation).

6

Yeah, I am not sure how #2102 is related at all. It is only for C FFI, and any access to a struct declared with an anonymous field is unsafe.

7

Can you elaborate more on why that would be substantially better?

One can always make the structs in a private module, or something, and add associated type aliases...

8

I think it would make more sense for the associated structs/enums/traits to be nested in an inherent impl block for the parent type since that's where rust already supports items:

struct MyStruct {
    field: Self::LocalType,
}

impl MyStruct {
    struct LocalType {
    }
    trait LocalTrait {
    }
    enum LocalEnum {
    }
}
5 Likes
9

Even though we can add associated type aliases, I still feel that it is kind of redundant when there's a possibility to declare associated structs/enums/traits inside a declaration or inherent impl.

10

Yeah, I think so; with those locating in an inherent impl could somehow prevent the overhead of implementing/supporting those in declarations.

11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.