<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 17 Aug 2017, at 11:42, Robert Bennett <<a href="mailto:rltbennett@icloud.com" class="">rltbennett@icloud.com</a>> 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 that doesn’t define its own ==/hashValue 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>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 <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><br class=""></div><div>It is no more comparable to a constrained extension than it is to a default implementation, as it is neither of these things; both of those are well defined by their very nature, this instead is utterly arbitrary. There is no justification that will make that any less true.</div></body></html>