<div><br><div class="gmail_quote"><div dir="auto">On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>&gt; wrote:</div><div><div style="word-wrap:break-word"><blockquote type="cite">Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:<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&#39;t compile until I&#39;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 &quot;my type will meet the requirements for this make, sure I do it&quot;, not &quot;please, please use some magic to do this for me&quot;; there needs to be a clear difference between the two.</blockquote></div><br><div>My conclusion isn&#39;t as pessimistic as yours, but I share your objections: Mixing a normal feature (protocols) with compiler magic doesn&#39;t feel right to me — wether it&#39;s Equatable, Hashable, Codable or Error.</div><div>It&#39;s two different concepts with a shared name*, so I think even AutoEquatable wouldn&#39;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&#39;t fight the feeling that the evolution process doesn&#39;t work well for proposals like this:</div><div>It&#39;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 &quot;hiding bugs.&quot; Yes, this feature cannot currently be implemented as a default protocol implementation without magic; with better reflection facilities there&#39;s a good chance that one day it might be, but that&#39;s not the reason why it&#39;s being compared to default protocol implementations. The reason for the comparison is that this feature only &quot;hides bugs&quot; like a default protocol implementation &quot;hides bugs&quot; (in the I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won&#39;t-remind-me-anymore sense of &quot;hiding bugs&quot;), and the addition of default protocol implementations, unless I&#39;m mistaken, isn&#39;t even considered an API change that requires Swift Evolution review.</div><div dir="auto"><br></div><div dir="auto">Given Swift&#39;s emphasis on progressive disclosure, I&#39;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&#39;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&#39;s enthusiasm for the feature, I do; I hate boilerplate as much as the next developer, but as you say, it&#39;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&#39;s a big part of the problem; the decisions here are not just about trimming boilerplate for Equatable/Hashable, it&#39;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>