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

[Matthew Johnson]

Sent from my iPad

> On May 29, 2016, at 8:25 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> 
> Should 'deriving' allows us to manually implement protocol requirements? For example
> struct A : deriving Hashable {
>  var hasValue : Int {...}
> }
> 
> Or there should be a compilation error in this case?

This should be an error.  If you want to implement it manually your should use the usual conformance declaration syntax.

> 
> Right now I feel that if we can have auto-deriving by using current syntax for protocol conformance - we sholdn't introduce new keyword and new rules for this.

We've already covered the reasons why this is problematic.  It's better to be explicit about the request for synthesized conformance.

> The requirement to explicitly conform your type to protocol for auto-deriving is IMO reasonable compromise between separate 'deriving' decoration and implicit derivation(when your type is Hashable without any conformance to protocol, just if each property is Hashable).
> 
>> On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On May 29, 2016, at 12:28 AM, Patrick Smith <pgwsmith at gmail.com
>> <mailto:pgwsmith at gmail.com>> wrote:
>> 
>>> Yeah I don’t see a problem. It’s the same way that protocol extensions
>>> just work. Think of this automatic synthesis as a really flexible
>>> protocol extension:
>>> 
>>> extension Hashable where Members : Hashable {
>>>  var hashValue : Int {
>>>    return self.allMembers.reduce(^) // Or whatever combiner is best
>>>  }
>>> }
>> 
>> Protocol extensions require you to declare conformance before your type
>> receives their implementation and it must be identical for all do
>> conforming types.
>> 
>> You should have to declare conformance to receive Equatable conformance and
>> synthesis.  IMO it makes sense to do that with 'deriving' which makes it
>> clear that you are requesting synthesized rather than manual conformance.
>> 
>>> 
>>> 
>>>> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> The problem with this is that it doesn’t differentiate between
>>>>> synthesized and manual conformance.  You won’t get error messages you
>>>>> otherwise would when you intend to supply manual conformance.  It is
>>>>> also less clear to a reader of the code that the default, compiler
>>>>> synthesized implementation is being generated.
>>>> 
>>>> I don’t think it’s reasonable to force the language down the path where
>>>> developers don’t have to be familiar with its features in order to use
>>>> them correctly. If types in Swift were to automatically gain Equatable
>>>> and Hashable conformances whenever they were used by something that
>>>> required them, that would be a core language feature, like type
>>>> inference, that even junior developers in the language would need to
>>>> know. Yet few (though not none) would insist that all types be manually
>>>> declared, despite otherwise not knowing when our type inference goes
>>>> wrong. It’s just a basic feature of the language that anyone using the
>>>> language should know about, otherwise it can bite them in the ass when
>>>> weird compiler errors start popping up.
>>>> Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast
>>>> majority of cases where my types are trivially equatable, I should just
>>>> be able to declare them as such and gain the compiler-synthesized ==. In
>>>> the cases where that’s not possible, the compiler can emit an error. And
>>>> in the cases where I want a custom == implementation I can provide it.
>>>> Requiring a new keyword and not making this feature as simple as
>>>> possible because the rare developer with a custom type who doesn’t want
>>>> the synthesized == they just said they did by declaring Equatable
>>>> conformance is an unnecessary defaulting to the rare case.
>>>> 
>>>> 
>>>> 
>>>> Jon Shier
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> 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
>>