C-COMMON-TRAITS and enums #99
Labels
amendment
Amendments to existing guidelines
clarification
I-nominated
Indicates that an issue has been nominated for discussion during a team meeting.
Can we expand the language of C-COMMON-TRAITS to help making decisions for enum types implementing non-trivial traits, specially
Ord
/PartialOrd
andDefault
?I think the question I face in designing the API is: how
Ord
/PartialOrd
andDefault
are used in common cases, specifically the standard library, and what functionalities users will be missing without the trait implementation.For example, I have a plain enum that has 25 variants. Ordering doesn't have any straightforward meaning for the type internally, but deriving
Ord
/PartialOrd
on the (currently) alphabetically-ordered list is easy to do.A similar situation with
Default
. This enum is representing a character property, which does have a default value for non-assigned Unicode code points. (Technically, the default value is different for some specific Unicode blocks, but there's on generic default value stated in the specs.) However, the implementation already takes that into account and always returns a value. And, the enum values are always fetched from a character, so there's no standalone instantiation which would require aDefault
value. So, again, obvious to derive, but almost meaning-less in usage.In Rust reference docs, it's clear that not providing
Hash
prevents using the type inHashMap
andHashSet
types. But, the reference doesn't mention anything aboutOrd
/PartialOrd
orDefault
being used in the standard library.An alternate would be to put some explanation about these traits in the reference doc to make it more clear how, if at all, they are used in the standard library.
What do you think?
The text was updated successfully, but these errors were encountered: