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

[Xiaodi Wu]

Yes, but to be clear, this is an objection that is equally applicable to
any change where a protocol requirement is given a default implementation.

Unless I’m mistaken, ordinarily, the addition of such a default
implementation isn’t even considered an API change and doesn’t require
Swift Evolution approval.
On Thu, Aug 10, 2017 at 16:41 David Ungar <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> 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> wrote:
>
>> Yes, thanks! Here’s the full proposal for those interested:
>> 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> wrote:
>>
>>
>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <
>> 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
>>
>> -Chris
>>
>>
>>
>> .
>>
>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <
>> 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
>> 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/20170810/dd879f22/attachment.html>