Just some quick answers, more discussion should be in the RFC thread.
It's just implemented for the variant, not the enum as a whole.
This one you could definitely make an argument that it should apply. A variant type is a direct subset type of the full enum type. I think the "best" solution would be to provide a default impl
, so the variant type could also provide a specialized impl? Or maybe monomorphized optimization could just make that specialized impl for you?
The default position if this concern isn't raised would be that no trait implementations would be implied, as they are separate types. However, IIRC, enum variant types coerce to the enum type, so (something something inference) it might "just work".
Almost certainly.
By refining the type to the type which implements the method. They're different types, after all!
I assume your point here is that what benefit you get over using newtype variants around actual normal distinct types. It's mostly convenience, but one actual additional power you get is to use &Enum::Variant
where &Enum
is expected (if the RFC allows that; the representation they argue for does allow for it to exist). (Namely, Enum::Variant
still carries the discriminant and padding with it, where a full wrapped EnumVariant
type doesn't and would need to be rewrapped to be used as an Enum
.)