> The problem with this is that it doesn’t differentiate between synthesized
> and manual conformance. You won’t get error messages you otherwise would
> when you intend to supply manual conformance. It is also less clear to a
> reader of the code that the default, compiler synthesized implementation is
> being generated.
I don’t think it’s reasonable to force the language down the path where
developers don’t have to be familiar with its features in order to use them
correctly. If types in Swift were to automatically gain Equatable and Hashable
conformances whenever they were used by something that required them, that
would be a core language feature, like type inference, that even junior
developers in the language would need to know. Yet few (though not none) would
insist that all types be manually declared, despite otherwise not knowing when
our type inference goes wrong. It’s just a basic feature of the language that
anyone using the language should know about, otherwise it can bite them in the
ass when weird compiler errors start popping up.
Frankly, IMO, this is an obvious case of 80/20 optimization. In the
vast majority of cases where my types are trivially equatable, I should just be
able to declare them as such and gain the compiler-synthesized ==. In the cases
where that’s not possible, the compiler can emit an error. And in the cases
where I want a custom == implementation I can provide it. Requiring a new
keyword and not making this feature as simple as possible because the rare
developer with a custom type who doesn’t want the synthesized == they just said
they did by declaring Equatable conformance is an unnecessary defaulting to the
rare case.
Jon Shier_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
