[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types
L Mihalkovic
laurent.mihalkovic at gmail.com
Mon May 30 11:48:50 CDT 2016
> On May 29, 2016, at 3:31 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>
> 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.
Considering it can all be done without deriving, so I wager they will never add it
>
>>
>> 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
>>>
>
> _______________________________________________
> 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/20160530/67c80086/attachment.html>
More information about the swift-evolution
mailing list