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

[Haravikk]

> On 17 Aug 2017, at 18:04, Chris Lattner <clattner at nondot.org> wrote:
>> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On 17 Aug 2017, at 11:42, Robert Bennett <rltbennett at icloud.com <mailto:rltbennett at icloud.com>> wrote:
>>> 
>>> Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.
>> 
>> And I disagree; this isn't a constraint extension either, not even close, we're talking here about automatic behaviour based upon variables the protocol knows literally nothing about, in a way that can result in new errors that are currently impossible (as you can't currently conform to Equatable without providing some kind of code to implement it).
> 
> I understand and recognize your concern.  Your points are apply equally to the default implementation of the Codable protocols as well, and the core team specifically discussed this.
> 
> Also, if I were to nitpick your argument a bit, it isn’t true that the protocol knows “nothing" about the type anyway, because the protocol has access to self.  The default implementation could conceptually use reflection to access all the state in the type: we’re producing the same effect with more efficient code.

Parts that the protocol specifically defines are fine, I've said as much; the part I object to is everything else as the issue here is that the protocol must make assumptions about the concrete type and I find that dangerous, especially on an existing protocol. I would argue that any default implementation using reflection to do the same is likewise flawed unless the behaviour is very carefully and very clearly defined as part of a contract that developers are explicitly opting in to.

But that's not what's happening here; Equatable is an existing and well understood protocol and you are proposing to change it arbitrarily to suddenly imply functionality that doesn't currently exist and which has the potential to introduce bugs.

I have seen not one shred of justification why this feature must be implicit through Equatable except that Codable does it, and frankly I don't find that even close to acceptable as a precedent at all as Codable is not preexisting, and personally I don't like it in Codable's case either, and wasn't aware of the discussion around it. But for Equatable we're talking about a preexisting protocol that will today catch 100% of missing conformance bugs, being changed such that that is no longer the case because of a default behaviour that will hide such bugs by making potentially flawed assumptions about a concrete type.

Frankly, setting a precedent for this kind of automated background reflective guesswork on basic protocols is a horrifying prospect to me, even more so if it is being introduced arbitrarily on existing protocols. At least with things like unit testing that reflect test methods the rules are clearly known from the outset (i.e- there's a clear naming convention for what is reflected, everything else is the developer's domain, you opt-in by following that naming convention), this is not the case here.

And what exactly is the burden from opting in explicitly? A different protocol name, a keyword or an attribute are not going to trouble developers, and will clarify exactly what they intended without hiding bugs. This is why I feel this hasn't been considered sufficiently at all, as no justification is given why "AutoEquatable" or whatever is somehow an unacceptable burden to clarify what a developer actually wanted.

For me the whole point of a basic protocol is that it forces me to implement some requirements in order to conform; I can throw a bunch of protocols onto a type and know that it won't compile until I've finished it, developers get distracted, leave things unfinished to go back to later, make typos etc. etc. To me declaring a conformance is a declaration of "my type will meet the requirements for this make, sure I do it", not "please, please use some magic to do this for me"; there needs to be a clear difference between the two.

This is an overreach, plain and simple. While it may seem small, I would frankly rather go back to coding everything in C++ than continue using Swift if this is to be the direction of travel, as there's a big a difference between convenience and trying to guess what a developer wanted. Cutting down on boilerplate is a fine goal, but it should be because I as the developer wanted it, not someone else who thinks they're doing me a favour despite knowing nothing about my code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/c4290902/attachment.html>