<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 May 2, 2016, at 9:44 AM, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I've written a proposal to formalize some of the discussion that was had over in the thread for the `FloatingPoint` protocol proposal regarding improvements to operator requirements in protocols that do not require named methods be added to the protocol and conforming types. Thanks to everyone who was participating in that discussion!</div></div></blockquote><div><br class=""></div><div>This is really great, thank you for pushing forward on this Tony! &nbsp;I am really optimistic that this will allow us to finally put to rest the weirdness we have with protocols and operators.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px;" class="">When a protocol wishes to declare operators that conforming types must implement, we propose adding the ability to declare operator requirements as static members of the protocol:</span></div><div class=""><div class="highlight highlight-source-swift" style="margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px"><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;padding:16px;overflow:auto;border-radius:3px;word-wrap:normal;word-break:normal;background-color:rgb(247,247,247)" class=""><span class="pl-k" style="color:rgb(167,29,93)">protocol</span> <span class="pl-c1" style="color:rgb(0,134,179)">Equatable</span> {
  <span class="pl-k" style="color:rgb(167,29,93)">static</span> <span class="pl-k" style="color:rgb(167,29,93)">func</span> <span class="pl-en" style="color:rgb(121,93,163)">==</span>(lhs: <span class="pl-k" style="color:rgb(167,29,93)">Self</span>, rhs: <span class="pl-k" style="color:rgb(167,29,93)">Self</span>) <span class="pl-k" style="color:rgb(167,29,93)">-&gt;</span> <span class="pl-c1" style="color:rgb(0,134,179)">Bool</span>
}</pre></div></div></div></blockquote><div>This sounds great. &nbsp;Operators are clearly “static" members, and adding the keyword here is great for consistency when you end up *implementing* an operator inline in a class. &nbsp;At that point, you want to see in the source where it is a “static” operator or a “class” operator (dynamic dispatch).</div><div><br class=""></div><div><div>You don’t include it as part of your proposal, but I’d strongly suggest that we deprecate and/or remove the existing non-static operator requirement syntax. &nbsp;I really don’t like ending up in a situation where we have both “instance” and “static” operators, where these two cases have different declaration and use syntax.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""></div></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px" class="">Then, the protocol author is responsible for providing a generic global&nbsp;<em style="box-sizing: border-box;" class="">trampoline</em>&nbsp;operator that is constrained by the protocol type and delegates to the static operator on that type:</p><div class="highlight highlight-source-swift" style="margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px"><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;padding:16px;overflow:auto;border-radius:3px;word-wrap:normal;word-break:normal;background-color:rgb(247,247,247)" class=""><span class="pl-k" style="color:rgb(167,29,93)">func</span> <span class="pl-en" style="color:rgb(121,93,163)">==</span> &lt;T: <span class="pl-c1" style="color:rgb(0,134,179)">Equatable</span>&gt;(lhs: T, rhs: T) <span class="pl-k" style="color:rgb(167,29,93)">-&gt;</span> <span class="pl-c1" style="color:rgb(0,134,179)">Bool</span> {
  <span class="pl-k" style="color:rgb(167,29,93)">return</span> T<span class="pl-k" style="color:rgb(167,29,93)">.==</span>(lhs, rhs)
}</pre></div><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;line-height:25.6px" class="">Types conforming to a protocol that contains static operators would implement the operators as static methods </p></div></div></blockquote><div>They can also be ‘class’ methods in a class.</div><div><br class=""></div><div>-Chris</div></div><br class=""></body></html>