<div><br><div class="gmail_quote"><div dir="auto">On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 19 Aug 2017, at 11:44, Tino Heth <<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>> wrote:</div><div><div style="word-wrap:break-word"><blockquote type="cite">Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br></blockquote><div><blockquote type="cite">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.</blockquote></div><br><div>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.</div><div>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.</div><div><br></div><div>Besides that specific concern, I can't fight the feeling that the evolution process doesn't work well for proposals like this:</div><div>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.</div><div><br></div><div>- Tino</div><div><br></div><div>* for the same reason, I have big concerns whenever someone proposes to blur the line between tuples and arrays</div></div></div></blockquote></div><br></div><div style="word-wrap:break-word"><div>Agreed. To be clear though; in spite of my pessimism this <b>is</b> a feature that I <b>do</b> 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.</div><div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.<br></div><div><br></div><div>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.</div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>