<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 17, 2017, at 1:04 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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 Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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 17 Aug 2017, at 11:42, Robert Bennett &lt;<a href="mailto:rltbennett@icloud.com" class="">rltbennett@icloud.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type&nbsp;that doesn’t define its own ==/hashValue&nbsp;while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.</span></div></div></div></blockquote><br class=""></div><div class="">And I disagree; this isn't a constraint extension either, not even close, we're talking here about automatic behaviour based upon variables the protocol knows literally&nbsp;<b class="">nothing</b> about, in a way that can result in new errors that are currently impossible (as you can't currently conform to Equatable without providing some kind of code to implement it).</div></div></div></blockquote><br class=""></div><div class="">I understand and recognize your concern. &nbsp;Your points are apply equally to the default implementation of the Codable protocols as well, and the core team specifically discussed this.</div><div class=""><br class=""></div><div class="">Also, if I were to nitpick your argument a bit, it isn’t true that the protocol knows “nothing" about the type anyway, because the protocol has access to self. &nbsp;The default implementation could conceptually use reflection to access all the state in the type: we’re producing the same effect with more efficient code.</div></div></div></blockquote></div><br class=""><div class="">I’ve proposed having alternative types (strong type-alias / subtypes / quotient types) in the recent past. A key feature is selectively copying the underlying type’s interface:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">alter PlagiarizedArray&lt;T&gt;: Array&lt;T&gt;, MutableCollection {</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">// Copy the interface of Array’s RandomAccessCollection, and forward them to super</font></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">publish RandomAccessCollection</font></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class=""><br class=""></font></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">/* Don’t do the same for MutableCollection. Either reverse that decision or implement the needed methods (that aren’t already part of RandomAccessCollection) manually. */</font></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">//...</font></div></blockquote></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">So, with these new/changed protocols, an alternative that declares conformance to Equatable / Hashable / Encodable / Decodable would effectively get a “publish Whatever” no-so-secretly added, right? That could mess up selective copying of the interface. Of course, both my method and synthesized conformance would just effectively forward to super, so is it a distinction without a difference?</div><div class=""><br class=""></div><div class="">I want alternative types in Swift 5. (They shouldn’t be too hard to implement. I’ve downloaded the compiler’s Git archive to try it out.) Once added, we will have a way to declare implicitly accessible methods, making the synthesized conformance here obsolete. At that point I think we should declare as such and require explicit “publish Equatable/Hashable/Encodable/Decodable/Codable” directives in non-alternatives declaring conformance.</div><div class=""><br class=""></div><div class="">A new problem is that (at least) one version of Swift would have come out by then. Would requiring explicit publishing break backwards compatibility? Could we migrate the code by suggesting to insert the appropriate publishing directives? Could we have a compatibility mode where these five protocols’ implicit synthesizing is grandfathered in, but all new protocols important enough to get this status must need an explicit directive?</div><div class=""><br class=""></div><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">—&nbsp;</div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com&nbsp;</div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></body></html>