This strikes me as another good way to look at it. Thanks guys,
- David > On Aug 10, 2017, at 2:54 PM, Robert Bennett <rltbenn...@icloud.com> wrote: > > @Xiaodi I have a slightly different view of this. Currently, if you have a > type that conforms to a protocol, and you do not need to write any additional > code in order for the type to conform to the protocol, then the protocol must > have default implementations of its requirements. Because some types will be > able to conform to Equatable/Hashable without writing out the code to satisfy > the == and hashValue requirements, that logic (which you may or may not > subscribe to) would dictate that there is a default implementation of those > requirements (in this case, a magical default implementation that works for > many different types; maybe it uses Mirrors) — it certainly “feels” like > there is a default implementation to the user. And thus from an ergonomic > standpoint, these issues are not really orthogonal, even if they are distinct > implementation-wise. > >> On Aug 10, 2017, at 5:41 PM, David Ungar <dun...@apple.com >> <mailto: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 >>> <mailto: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 <mailto: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 >>> >>> <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 >>>> <mailto:clatt...@nondot.org>> wrote: >>>> >>>>> >>>>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution >>>>> <swift-evolution@swift.org <mailto: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 >>>> <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 <mailto: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 <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
