Thanks for your feedback, everybody! I've updated the gist <https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad> to reflect what seems to be a consensus here:
* Derived conformances are now opt-in (this makes the recursive case *much* cleaner, and the complexity involved in that section has been completely removed) * Classes are supported now as well Please take a look at the updated version and let me know if there are any concerns! If folks like it, I'll prepare a pull request. On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon < >> br...@architechies.com> wrote: >> >>> I would think only final classes could participate in this, since a >>> subclassable class would need to allow subclasses to override equality, and >>> you can't override a static `==` operator method. >>> >> >> I work so rarely with classes that I'm embarrassed to have to ask this >> question: can classes not satisfy Equatable with a `public class func ==`? >> > > Currently: > > class C: Equatable { > class func == (lhs: C, rhs: C) -> Bool { > return lhs === rhs > } > } > > Yields an error, “Operator '==' declared in non-final class 'C' must be > 'final'”. > > Nevin > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution