> 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
