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

[Xiaodi Wu]

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/f69699a5/attachment.html>