-
-
Couldn't load subscription status.
- Fork 4.2k
Description
What problem does this solve or what need does it fill?
Reflected enums do not support SerializationData. This is because SerializationData works for a single set of fields but enums can have multiple (one set per variant).
This means that we #[reflect(skip_serializing)] is ignored for a variant's fields. For example, this does nothing:
#[derive(Reflect)]
enum Foo {
A {
#[reflect(skip_serializing)]
value: i32,
}
}What solution would you like?
Ideally we should enable this behavior on enums. They should register and store the ignored set per variant. To do so, we probably need to change SerializationData into an enum with one variant for structs and another for enums.
Alternatively, we could rethink SerializationData and make its data available on the TypeInfo itself (or on the individual NamedField and UnnamedField info structs). The reason we might not want to do this is doing so begins to (1) add bloat to those structs and (2) tightly couple reflect-related logic with reflection itself. It might be okay for just this attribute, but we may want to be cautious of how much we make "intrinsic" to reflection.
What alternative(s) have you considered?
We could potentially just disallow this behavior. That's definitely not ideal but we could easily add a compile error if this attribute is placed on a variant's field.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status