Sorry, I think I misunderstood your earlier email. I believe we are in agreement.
> On Aug 10, 2017, at 5:54 PM, Xiaodi Wu <[email protected]> wrote: > > 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 <[email protected]> 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 <[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]> 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 <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution >>>>>> <[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 >>>>> >>>>> -Chris >>>>> >>>>> >>>>> >>>>>> . >>>>>> >>>>>>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution >>>>>>> <[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] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
