[swift-evolution] SE-0185 Synthesizing Equatable and Hashable conformance

Robert Bennett rltbennett at icloud.com
Thu Aug 10 14:23:45 CDT 2017


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



More information about the swift-evolution mailing list