<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 13, 2016, at 12:12 AM, Patrick Pijnappel 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 dir="ltr" class="">For some protocols we'd like to require top-level (free) functions, e.g. for many math functions such as <font face="monospace, monospace" class="">abs()</font> or <font face="monospace, monospace" class="">sin()</font>. We already do this implicitly for operators. </div></div></blockquote><div><br class=""></div><div>Hi Patrick,</div><div><br class=""></div><div>FYI, we’re very likely to remove this special behavior for operators, by making operator requirements only find operators declared in a conforming type. This would eliminate the special case for operators that exists now, and has other advantages as well. Check out this proposal for more information:</div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md</a></div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><b class="">Proposal</b></div><div class="">Allow top-level function/property requirements in protocols, e.g.:</div><div class=""><br class=""></div><div class=""><table class="" style="border-spacing:0px;border-collapse:collapse;color:rgb(51,51,51);font-family:Helvetica,arial,nimbussansl,liberationsans,freesans,clean,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:13px"><tbody style="" class=""><tr style="" class=""><td id="LC141" class="" style="padding:0px 10px;vertical-align:top;overflow:visible;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:12px;word-wrap:normal;white-space:pre"><span class="" style="color:rgb(167,29,93)">public</span> <span class="" style="color:rgb(167,29,93)">protocol</span> <span class="" style="color:rgb(0,134,179)">AbsoluteValuable</span> <span class="" style="color:rgb(167,29,93)">:</span> SignedNumber {
<span class="" style="color:rgb(150,152,150)">/// Returns the absolute value of `x`.
</span><span style="color:rgb(167,29,93)" class=""> @warn_unused_result
</span><span class="" style="color:rgb(167,29,93)"> toplevel</span> <span class="" style="color:rgb(167,29,93)">func</span> <span class="" style="color:rgb(121,93,163)">abs</span>(<span class="" style="color:rgb(121,93,163)">_</span> <span class="">x</span>: <span class="" style="color:rgb(167,29,93)">Self</span>) <span class="" style="color:rgb(167,29,93)">-></span> Self
}</td></tr></tbody></table><div class=""><br class=""></div><div class="">We'd probably want to require this for operators. This also opens up syntax if we ever get dynamically dispatched operators.</div><div class=""><div style="margin: 0px; font-size: 12px; line-height: normal; font-family: Consolas; color: rgb(0, 134, 179);" class=""><span style="color:rgb(167,29,93)" class=""><br class=""></span></div><table class="" style="border-spacing:0px;border-collapse:collapse;color:rgb(51,51,51);font-family:Helvetica,arial,nimbussansl,liberationsans,freesans,clean,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:13px"><tbody style="" class=""><tr style="" class=""><td id="LC98" class="" style="padding:0px 10px;vertical-align:top;overflow:visible;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:12px;word-wrap:normal;white-space:pre"><span class="" style="color:rgb(167,29,93)">public</span> <span class="" style="color:rgb(167,29,93)">protocol</span> SignedNumber <span class="" style="color:rgb(167,29,93)">:</span> <span class="" style="color:rgb(0,134,179)">Comparable</span>, <span class="" style="color:rgb(0,134,179)">IntegerLiteralConvertible</span> {
<span class="" style="color:rgb(150,152,150)">/// Returns the result of negating `x`.
</span> <span class="" style="color:rgb(167,29,93)">@warn_unused_result
toplevel </span><span class="" style="color:rgb(167,29,93)">prefix</span> <span class="" style="color:rgb(167,29,93)">func</span> <span class="" style="color:rgb(121,93,163)">-</span> (x: <span class="" style="color:rgb(167,29,93)">Self</span>) <span class="" style="color:rgb(167,29,93)">-></span> Self
}</td></tr></tbody></table></div></div><div class=""><div class=""><br class=""></div><div class="">Currently this is done using the combination of a static method and a top-level generic function on that protocol. As I understand that approach does have some benefits in terms of type-checker performance, though I'm not sure whether that is likely to stay relevant in the future.</div><div class=""><br class=""></div><div class=""><b class="">Advantages</b></div></div><div class=""><ul class=""><li class="">Cleaner than current approach (esp. floating point types have tons of top-level functions)</li><li class="">Makes operators less of a special case</li><li class="">Opens up syntax for member operators</li><li class="">Could also apply to top-level properties (esp. useful if we get generic properties, for e.g. π<...>)</li></ul></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=""></body></html>