I often organize my associated values for readability and clarity. I haven't found myself wanting
Comparable conformance for these enums, but if I did this may not correspond with the natural comparison order. I don't find modifiers to be any stronger a reason for determining source order than these concerns.
If we're going to trust that users opting-in to
Comparable synthesis want source order for associated values I think we should consider extending the same trust to structs and properties. We should certainly have a stronger reason for treating structs differently than enums than "sometimes people like to group declarations with the same modifiers together".
Tuples are anonymous product types and structs are nominal product types. I don't see a strong distinction here. There is a wide range of complexity in structs. Many are as simple as tuples are, but with a name for the type.
The existing opt-in synthesis of
Equatable for structs works fine as well. I'm sure some people would find it unexpected for
Comparable synthesis to work on enums but not structs.
I don't have a strong opinion about the right direction, but I think the proposal as drafted sits in a valley of inconsistency.