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

[Tony Allevato]

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 at swift.org> wrote:

> On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <
>> 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
> 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/fc73171a/attachment.html>