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

[Vladimir.S]

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?

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.
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
>