[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Vladimir.S svabox at gmail.com
Mon May 30 16:12:53 CDT 2016


In case we discuss this feature not for just value types but for classes 
also - will such AutoEquatable allows to implement protocol manually?

Now we can have:

func == (lhs: A, rhs: A) -> Bool { return true }
class A: Hashable { var hashValue: Int { return 100 } }
class B: A { override var hashValue: Int { return 200 } }

So, if we'll have
class A: AutoHashable { }
or
class A: deriving Hashable { }
will we be able to have:
class B: A { override var hashValue: Int { return 200 } }
?

(The same question was for `deriving` proposal)
Please note that we probably don't want/have no rights to modify the 
definition of class A.

There is no such question for auto-derived Hashable in case of simple 
conformance as we do now `class A: Hashable`.

On 30.05.2016 23:45, David Sweeris wrote:
> What about declaring the requirements for auto-conformance in a sub-protocol?
> @auto protocol AutoEquatable : Equatable {
>     //"syntax" for how to conform to Equatable
> }
>
> struct Foo : AutoEquatable {} //the compiler automatically synthesizes everything
> struct Bar : Equatable {} //you manually conform
>
> It would be a compiler error to conform to an `@auto` protocol if the compiler couldn't apply the provided "syntax" to the conforming type.
>
> (I have no clue what this "syntax" could be, other than some expansion of generics and/or a macro system)
>
> Anyway, does that help? It satisfies both the "explicit conformance" crowd and the "no new keywords" (at least at the "call" site) crowd.
>
> - Dave Sweeris
>
>> On May 30, 2016, at 15:26, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> I see these two groups: both wants explicit conformance to protocols, but first thinks that current syntax is enough (`: Equatable`) and second thinks we should introduce new keyword `deriving` for this(`: deriving Equatable`). I see no opinions(except the one opinion in proposal itself) to automatically deriving without explicit decoration.
>


More information about the swift-evolution mailing list