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 <dun...@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...@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@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 <clatt...@nondot.org> wrote: >> >> >> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution < >> swift-evolution@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution