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

[Xiaodi Wu]

On Sat, Aug 19, 2017 at 1:13 PM, Goffredo Marocchi <panajev at gmail.com>
wrote:

> We can override the protocol default implementation in the extension, but
> the issue I see with default implementation in Swift is that if I pass the
> object created this way around in a type erased container (Any : Protocol1
>   like it was common for many to pass id<Protocol> around in the
> Objective-C days, a good practice IMHO) then my overrode would not be
> called, but the default implementation will be used instead. I would be far
> more comfortable with this “magic” provided for free of default
> implementations were dynamically dispatched.
>

Are you referring to protocol extension methods? Those are not default
implementations, do not have a corresponding protocol requirement that can
be overridden, and are not what's being discussed here.


Sent from my iPhone
>
> On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 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
>>
> _______________________________________________
> 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/8f1d326e/attachment.html>