> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote: > > Thanks for your feedback, everybody!
Thanks for continuing to drive this forward! > > 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) Can the opt-in conformance be declared in an extension? If so, can the extension be in a different module than the original declaration? If so, do you intend any restrictions, such as requiring all members of the type declared in a different module to be public? My initial thought is that this should be possible as long as all members are visible. > * 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. Will the synthesis for classes dispatch through a non-final method which is expected to be overridden by subclasses? You don’t explicitly state this but it seems implied. If so, what if the subclass requires a custom implementation? This would require the signature of the non-final method to be part of the synthesis contract. Supporting non-final classes introduces enough complexity (especially when multiple modules are involved). I would hate to see it get sidetracked in discussions regarding non-final classes and miss the Swift 4 window because of that. Given the limited time left for Swift 4 it might be better to keep the initial proposal simpler and consider a followup in the Swift 5 timeframe to build on the initial proposal. > > > On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <br...@architechies.com > <mailto: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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
