<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, May 18, 2016 at 1:37 PM Nicola Salmoria &lt;<a href="mailto:nicola.salmoria@gmail.com">nicola.salmoria@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 18, 2016 at 10:27 PM, Tony Allevato <span dir="ltr">&lt;<a href="mailto:allevato@google.com" target="_blank">allevato@google.com</a>&gt;</span> 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_quote"><div><div><div dir="ltr"><br></div></div></div><div>What I&#39;m saying is, if you look at the Swift 3 branch of stdlib, global operator functions still do not have argument labels. Picking one at random: <a href="https://github.com/apple/swift/blob/swift-3.0-branch/stdlib/public/core/String.swift#L329" target="_blank">https://github.com/apple/swift/blob/swift-3.0-branch/stdlib/public/core/String.swift#L329</a></div><div><br></div><div>If you&#39;re arguing that those functions should be forced to include `_` placeholders, that&#39;s fine, but it&#39;s not accurate to say that the way they&#39;re written in this proposal is a step backwards from all the progress made in Swift 3. It is *consistent* with the way global operator functions are currently declared in Swift 3.</div><div><br></div><div>If it changes there, then it should change here as well. But they should be the same, and making that change for global operator functions is not part of the scope of this proposal.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I&#39;m not talking about the global operator functions; I&#39;m talking about the methods inside the protocol, which are methods and are called like methods; they are not operators.</div></div></div></div></blockquote><div><br></div><div>They&#39;re methods that have names that are operators, so the proposal treats them like other functions that have names that are operators.</div><div><br></div><div>In Swift 3, there are two types of global functions:</div><div>1) Functions with names that are not operators, which have mandatory argument labels; e.g., `func abs(_ x: Int)`</div><div>2) Functions with names that are operators, which mandatorily *lack* argument labels; e.g., `func +(lhs: Int, rhs: Int)`</div><div><br></div><div>Static methods are just functions that are attached to a class type; why introduce more inconsistency by requiring labels on them as methods but not as global functions? This way, an operator as a static requirement of a protocol looks just like the global operator that matches it.</div><div><br></div><div>Similarly, if you pass a bare operator into another algorithm (like `reduce`), you call it without any argument labels, so there are already situations where calling an operator in that way (even though it&#39;s indirect) omits the labels.</div><div><br></div><div>I can&#39;t entirely disagree that there is inconsistency here; but IMO the inconsistency is with operator functions *in general* lacking labels, not with the treatment of them proposed here.</div><div><br></div></div></div>