SE-0266 — Synthesized Comparable conformance for enum types

[anandabits (Matthew Johnson)]

@Ben_Cohen

We discussed suggesting extending it to structs as well, but felt that would be a little more controversial. (for example, today you can reorder stored properties on a struct without it making a semantic difference, but this is not true of associated values). We felt it would be a natural break in the feature to support enums but not structs. This does not mean we are for or against adding struct support in future, but that would be proposed as a separate proposal. This allows us to make progress on accepting what will be a very beneficial feature now, with room for expansion later.

Thank you (and @allevato) for providing the rationale. It's worth pointing out that you can re-order enum cases today without a semantic difference. So this proposal already introduces source-order semantics that do not exist today. That said, I mostly just wanted to make sure these issues were being carefully considered. That was not evident in the proposal document. The details in this thread including rationale, alternatives and possible future direction of structs should be captured in an update to the document.

I still think we should consider in this review whether the @memberwise annotation included in the differentiable programming manifesto is a good idea or not, and if it is whether it is relevant to this proposal. The rationale is that a memberwise-synthesized conformance "doesn't make sense as a default implementation in all cases". That feels loosely similar to the source-order dependence of this proposal. In both cases, the attribute provides an indication that the programmer needs to carefully consider the semantics of the synthesized implementation.