- What is your evaluation of the proposal?
It feels incomplete. For example, the proposal does not discuss enums with cases that have multiple associated values, all of which are Comparable.
I'm going to guess that the intent in this case is lexicographical ordering. If that is the case, it isn't clear why using lexicographical comparison of enums with multiple associated values should be considered acceptable where synthesis of lexicographical comparison of struct properties using source order is not. If both are acceptable, the proposal should include synthesis of Comparable for structs. If lexicographical comparison is never acceptable, the proposal needs to more clearly document its limitations. If there is a reason it is acceptable for associated values but not for struct properties, that reason should be stated clearly.
Aside from these changes, if we're going to adopt the approach of @memberwise for opt-in synthesis suggested by the Differentiable Programming Mega-Proposal maybe this would be a good place to start.
- Is the problem being addressed significant enough to warrant a change to Swift?
Yes, the author makes a good case for supporting opt-in synthesis of Comparable for enums based on case order.
- Does this proposal fit well with the feel and direction of Swift?
I think it has some rough edges that need work, but otherwise it is consistent with the general approach used in Swift.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
n/a
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick read.