[swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

[David Ungar]

This strikes me as another good way to look at it.

Thanks guys,

- David

> On Aug 10, 2017, at 2:54 PM, Robert Bennett <rltbennett at icloud.com> wrote:
> 
> @Xiaodi I have a slightly different view of this. Currently, if you have a type that conforms to a protocol, and you do not need to write any additional code in order for the type to conform to the protocol, then the protocol must have default implementations of its requirements. Because some types will be able to conform to Equatable/Hashable without writing out the code to satisfy the == and hashValue requirements, that logic (which you may or may not subscribe to) would dictate that there is a default implementation of those requirements (in this case, a magical default implementation that works for many different types; maybe it uses Mirrors) — it certainly “feels” like there is a default implementation to the user. And thus from an ergonomic standpoint, these issues are not really orthogonal, even if they are distinct implementation-wise.
> 
>> On Aug 10, 2017, at 5:41 PM, David Ungar <dungar at apple.com <mailto:dungar at apple.com>> wrote:
>> 
>> As long as I've been clear that the adoption of *this* proposal would transform a misspelling from a bug that the compiler catches to a bug that the compiler does not catch, I feel that my objection has been heard.
>> 
>> Thank you all,
>> 
>> - David
>> 
>>> On Aug 10, 2017, at 1:51 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>>> 
>>> Right. The objection raised is applicable to the overriding of any default implementation. However. _this_ proposal under review is about the synthesis of a default implementation, and we shouldn’t try to invent new syntax to address an orthogonal issue—and only partially at that.
>>> On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Yes, thanks! Here’s the full proposal for those interested: https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md <https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/XXXX-role-keywords.md>
>>> 
>>> I think that if we want to deal with the issue of some mistake arising from conforming to Equatable and/or Hashable, it should be through that proposal, not something specific to Equatable and Hashable. This sort of issue should not count against this Equatable/Hashable proposal.
>>> 
>>>> On Aug 10, 2017, at 3:39 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>>>> 
>>>>> 
>>>>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> I could have sworn that this sort of issue came up on this list earlier this year… Someone proposed a mechanism encompassing all protocols, not just Equatable and Hashable, to handle the issue of mistakenly believing you’re overriding a default implementation. Having trouble finding it at the moment.
>>>> 
>>>> Is this what you’re thinking of?
>>>> https://github.com/apple/swift-evolution/pull/724 <https://github.com/apple/swift-evolution/pull/724>
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>> 
>>>>> .
>>>>> 
>>>>>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> If I understand it, merely adding Equatable or Hashable will cause the compiler to synthesize requirements. This syntax opens up the possibility for errors:
>>>>>> 
>>>>>> struct Snort: Hashable {
>>>>>> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
>>>>>> }
>>>>>> 
>>>>>> In the above example, the programmer meant to implement hashValue but misspelled it.
>>>>>> With the proposal as-is, the error could be covered up.
>>>>>> 
>>>>>> I would prefer to see a different syntax than merely adding conformance to "HashValue", in order to distinguish the two cases: explicit supplying the requirement vs synthesis.
>>>>>> 
>>>>>> Also, what if we want to extend this idea to other protocols? Perhaps some sort of modifier on the protocol name would be more orthogonal:
>>>>>> 
>>>>>> struct Foo: Synth Hashable, Equatable 
>>>>>> 
>>>>>> Would say that Hashable requirements get synthesized but Equatable ones do not.
>>>>>> 
>>>>>> Alternatively, it might be clearer, though more verbose to move the signalling inside:
>>>>>> 
>>>>>> struct Snort: Hashable {
>>>>>> synth hashValue
>>>>>> }
>>>>>> 
>>>>>> (I don't advocate this specific syntax, btw.) But it has the virtual of possibly making it clearer to read the code.
>>>>>> 
>>>>>> TL;DR: I favor the proposal but would prefer modification to make it more explicit.
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170810/86168843/attachment.html>