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
