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

[Xiaodi Wu]

On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <brent at architechies.com>
wrote:

> On May 4, 2017, at 3:01 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hmm, I can see the appeal of automatically deriving Equatable and Hashable
> conformance, but I'd like that to be opt-in. That is, types should declare
> that they are Equatable or Hashable to begin with. It wouldn't have to take
> extra syntax, as compiler magic could effectively synthesize default
> implementations for == and/or hashValue when all members are themselves
> Equatable or Hashable, respectively.
>
>
> Another benefit is that the problem you're currently having with recursion
> goes away: from outside the type, you merely need to check if conformance
> is declared.
>
> Explicit with no special syntactic marker is definitely the way to go. It
> would work just like Codable is slated to.
>

Right. I think we've got broad agreement (woohoo!) that this is the sweet
spot.


> With such a scheme, consideration can be made to accommodating classes too.
>
>
> 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 ==`?

(My time is not unlimited right now, but I'd be willing to help with either
> the proposal or its implementation. This would be a great thing to get into
> Swift 4.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/fabee310/attachment.html>