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 <[email protected]> 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 >>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
