<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 14 Apr 2017, at 02:58, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Jaden, the proposal literally says that a compiler feature named "@_implements" is necessary for the proposed design to work. You can see WIP for that feature in the apple/swift repo.</div><div class=""><br class=""></div><div class=""><br class=""><div class="gmail_quote"><div class="">On Thu, Apr 13, 2017 at 19:55 Jaden Geller <<a href="mailto:jaden.geller@gmail.com" class="">jaden.geller@gmail.com</a>> wrote:<br class=""></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" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 13, 2017, at 5:18 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_4552979852900219286Apple-interchange-newline"><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Actually, the fact that this behavior cannot even be achieved without currently non-existent compiler features means that it is not possible to understand what's truly going on without reading *this document*, after mastering *both* IEEE floating point *and* Swift generics/protocols/extensions/static vs. dynamic dispatch. All to use `==` correctly. Which is to say, most people will simply not even know if they happen to be using the `==` they did not intend to use.</div><br class="m_4552979852900219286Apple-interchange-newline"></div></blockquote></div><br class=""></div><div style="word-wrap:break-word" class=""><div class="">If I understand correctly, I think you’re mistaken. The compiler already selects overloads based on generic context. If `T: FloatingPoint`, then it’ll choose the `==` with signature `<T: FloatingPoint> (T, T) -> Bool`. If `T: Equatable`, then it’ll choose the `==` with signature `<T: Equatable> (T, T) -> Bool`. No new compiler features are necessary for this specific behavior.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Jaden Geller</div></div></blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""><div class="">And actually, it’s a shame that kind of just snuck in as a footnote, because I think it is needed in the language anyway.</div><div class=""><br class=""></div><div class="">I’ve thought about more direct approaches to tackling this problem, such as “conformance regions” or named conformances (compiler-generated wrapper structs), which could allow you to conform to the same protocol more than once with special resolution features (e.g. think String.CharacterView being the default, named “Collection” conformance for String), or to manually specify which members get resolved as witnesses.</div><div class=""><br class=""></div><div class="">But in this proposal it’s just an implementation detail. We still don’t have a general solution to conflicting names for the members of different protocols.</div><div class=""><br class=""></div><div class="">- Karl</div></body></html>