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

[Xiaodi Wu]

On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 19 Aug 2017, at 11:44, Tino Heth <2th at gmx.de> wrote:
>
> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution <
> swift-evolution at swift.org>:
>
> 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.
>
>
> My conclusion isn't as pessimistic as yours, but I share your objections:
> Mixing a normal feature (protocols) with compiler magic doesn't feel right
> to me — wether it's Equatable, Hashable, Codable or Error.
> It's two different concepts with a shared name*, so I think even
> AutoEquatable wouldn't be the right solution, and something like #Equatable
> would be a much better indicator for what is happening.
>
> Besides that specific concern, I can't fight the feeling that the
> evolution process doesn't work well for proposals like this:
> It's a feature that many people just want to have as soon as possible, and
> concerns regarding the long-term effects are more or less washed away with
> eagerness.
>
> - Tino
>
> * for the same reason, I have big concerns whenever someone proposes to
> blur the line between tuples and arrays
>
>
> Agreed. To be clear though; in spite of my pessimism this *is* a feature
> that I *do* want, but I would rather not have it at all than have it
> implemented in a way that hides bugs and sets a horrible precedent for the
> future.
>

This was already touched upon during review, but to reiterate, the analogy
to default protocol implementations is meant specifically to address this
point about "hiding bugs." Yes, this feature cannot currently be
implemented as a default protocol implementation without magic; with better
reflection facilities there's a good chance that one day it might be, but
that's not the reason why it's being compared to default protocol
implementations. The reason for the comparison is that this feature only
"hides bugs" like a default protocol implementation "hides bugs" (in the
I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
sense of "hiding bugs"), and the addition of default protocol
implementations, unless I'm mistaken, isn't even considered an API change
that requires Swift Evolution review.

Given Swift's emphasis on progressive disclosure, I'm fairly confident that
once reflection facilities and/or code-generation facilities improve, many
boilerplate-y protocol requirements will be given default implementations
where they cannot be written today. With every advance in expressiveness,
more protocol requirements that cannot currently have a default
implementation will naturally acquire them. Since the degree to which the
compiler will cease to give errors about non-implementation is directly in
proportion to the boilerplate reduced, it's not a defect but a feature that
these compiler errors go away. At the moment, it is a great idea to enable
some of these improvements for specific common use cases before the general
facilites for reflection and/or code-generation are improved in later
versions of Swift, since the user experience would be expected to remain
the same once those full facilities arrive.

I realise I may seem to be overreacting, but I really do feel that strongly
> about what I fully believe is a mistake. I understand people's enthusiasm
> for the feature, I do; I hate boilerplate as much as the next developer,
> but as you say, it's not a reason to rush forward, especially when this is
> not something that can be easily changed later.
>
> That's a big part of the problem; the decisions here are not just about
> trimming boilerplate for Equatable/Hashable, it's also about the potential
> overreach of every synthesised feature now and in the future as well.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170819/bde2e898/attachment.html>