<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Operators will overload the function with new arguments. That's why I suggested this change in syntax only for operators and force them to have the first argument or the type Self.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">- Leonardo</div></div></div>
<br><div class="gmail_quote">On 14 May 2016 at 03:39, Patrick Pijnappel via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm good point. Defining a toplevel function or property could reserve that name in toplevel scope, but you'd be in trouble when two protocols from different modules require a toplevel function or property with the same signature.<div><br></div><div>I'm not sure how operators deal with this because they should have the same problem...<div><div class="h5"><div><br>On Friday, 13 May 2016, Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">To me this makes more sense for operators than for other functions or properties. For the former you could create conflict with previously declared function (or properties with variables) and there is no restriction in Swift that says you cannot or should not create a top level function or property.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">In this sense, having an operator declared inside a class/struct/enum would already make them top level as you proposed, no need for another keyword. I would only add one requirement: that the first argument should always be of type Self (and have it checked by the compiler). It ensures the operator operates on that type and helps minimising conflicts with a previously declared operator.</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">- Leonardo</div></div></div>
<br><div class="gmail_quote">On 13 May 2016 at 04:12, Patrick Pijnappel via swift-evolution <span dir="ltr"><<a>swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">For some protocols we'd like to require top-level (free) functions, e.g. for many math functions such as <font face="monospace, monospace">abs()</font> or <font face="monospace, monospace">sin()</font>. We already do this implicitly for operators. <div><br></div><div><b>Proposal</b></div><div>Allow top-level function/property requirements in protocols, e.g.:</div><div><br></div><div><table 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><tr><td 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-wrap"><span style="color:rgb(167,29,93)">public</span> <span style="color:rgb(167,29,93)">protocol</span> <span style="color:rgb(0,134,179)">AbsoluteValuable</span> <span style="color:rgb(167,29,93)">:</span> SignedNumber {
<span style="color:rgb(150,152,150)">/// Returns the absolute value of `x`.
</span><span style="color:rgb(167,29,93)"> @warn_unused_result
</span><span style="color:rgb(167,29,93)"> toplevel</span> <span style="color:rgb(167,29,93)">func</span> <span style="color:rgb(121,93,163)">abs</span>(<span style="color:rgb(121,93,163)">_</span> <span>x</span>: <span style="color:rgb(167,29,93)">Self</span>) <span style="color:rgb(167,29,93)">-></span> Self
}</td></tr></tbody></table><div><br></div><div>We'd probably want to require this for operators. This also opens up syntax if we ever get dynamically dispatched operators.</div><div><p style="margin:0px;font-size:12px;line-height:normal;font-family:Consolas;color:rgb(0,134,179)"><span style="color:rgb(167,29,93)"><br></span></p><table 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><tr><td 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-wrap"><span style="color:rgb(167,29,93)">public</span> <span style="color:rgb(167,29,93)">protocol</span> SignedNumber <span style="color:rgb(167,29,93)">:</span> <span style="color:rgb(0,134,179)">Comparable</span>, <span style="color:rgb(0,134,179)">IntegerLiteralConvertible</span> {
<span style="color:rgb(150,152,150)">/// Returns the result of negating `x`.
</span> <span style="color:rgb(167,29,93)">@warn_unused_result
toplevel </span><span style="color:rgb(167,29,93)">prefix</span> <span style="color:rgb(167,29,93)">func</span> <span style="color:rgb(121,93,163)">-</span> (x: <span style="color:rgb(167,29,93)">Self</span>) <span style="color:rgb(167,29,93)">-></span> Self
}</td></tr></tbody></table></div></div><div><div><br></div><div>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><br></div><div><b>Advantages</b></div></div><div><ul><li>Cleaner than current approach (esp. floating point types have tons of top-level functions)</li><li>Makes operators less of a special case</li><li>Opens up syntax for member operators</li><li>Could also apply to top-level properties (esp. useful if we get generic properties, for e.g. π<...>)</li></ul></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>