What problem does this solve or what need does it fill?
#4761 added the ability to reflect enums. With this, it also allowed for entire variants to be excluded from reflection using the #[reflect(ignore)] attribute. As mentioned in this comment, this can cause some problems.
Essentially, the code will panic if we try to call certain methods on an ignored variant.
#[derive(Reflect)]
enum Foo {
#[reflect(ignore)]
Bar
}
let value = Foo::Bar;
let name = Enum::variant_name(&value); // <-- PANIC!
What solution would you like?
Remove the ability to ignore entire variants (along with the relevant tests).
What alternative(s) have you considered?
Other solutions could be to:
- Allow ignored variants to be used by certain methods
- Return default-able values (
Option<T> rather than T)
- Ignore only the fields within the variant, not the variant itself
Option 1 is probably the best, but now we break the reflection promise that the variant is ignored since we have to use and return its data.
Option 2 negatively affects ergonomics.
Option 3 is okay, but it's not obvious that we are ignoring the fields and not the variant itself.
What problem does this solve or what need does it fill?
#4761 added the ability to reflect enums. With this, it also allowed for entire variants to be excluded from reflection using the
#[reflect(ignore)]attribute. As mentioned in this comment, this can cause some problems.Essentially, the code will panic if we try to call certain methods on an ignored variant.
What solution would you like?
Remove the ability to ignore entire variants (along with the relevant tests).
What alternative(s) have you considered?
Other solutions could be to:
Option<T>rather thanT)Option 1 is probably the best, but now we break the reflection promise that the variant is ignored since we have to use and return its data.
Option 2 negatively affects ergonomics.
Option 3 is okay, but it's not obvious that we are ignoring the fields and not the variant itself.