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 
> <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
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to