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.
> 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
