<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 19 Aug 2017, at 11:44, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""></blockquote><div class=""><blockquote type="cite" class="">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 class=""><div class="">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 class="">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 class=""><br class=""></div><div class="">Besides that specific concern, I can't fight the feeling that the evolution process doesn't work well for proposals like this:</div><div class="">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 class=""><br class=""></div><div class="">- Tino</div><div class=""><br class=""></div><div class="">* 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 class=""><div class="">Agreed. To be clear though; in spite of my pessimism this <b class="">is</b> a feature that I <b class="">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></blockquote><div><br class=""></div><div>I tried to make a split thread for this, but would you object to synthesized conformance if we had to explicitly add a command within the definition block to trigger the synthesis? If we add strong type-aliases, we could reuse the directive to copy an interface (method, inner type, property, or conformed-to protocol) from the underlying type to the current type for synthesis too. The only problem would be backward compatibility; once added, we would urge users to explicitly list “publish Equatable” for synthesis, but what about code that already uses the implicit version (since this feature will probably be released for at least one Swift version by the time strong type-aliases happen), do we force users to change their code?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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></div></blockquote></div><br class=""><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></body></html>