[swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

[Matthew Johnson]

> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution <swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
> On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/50771c0b/attachment.html>