Description
Can we expand the language of C-COMMON-TRAITS to help making decisions for enum types implementing non-trivial traits, specially Ord/PartialOrd and Default?
I think the question I face in designing the API is: how Ord/PartialOrd and Default 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 a Default 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 in HashMap and HashSet types. But, the reference doesn't mention anything about Ord/PartialOrd or Default 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?