[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Tony Allevato]

On Wed, May 18, 2016 at 1:37 PM Nicola Salmoria <nicola.salmoria at gmail.com>
wrote:

> On Wed, May 18, 2016 at 10:27 PM, Tony Allevato <allevato at google.com>
> wrote:
>
>>
>> What I'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:
>> https://github.com/apple/swift/blob/swift-3.0-branch/stdlib/public/core/String.swift#L329
>>
>> If you're arguing that those functions should be forced to include `_`
>> placeholders, that's fine, but it's not accurate to say that the way
>> they'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.
>>
>> 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.
>>
>
> I'm not talking about the global operator functions; I'm talking about the
> methods inside the protocol, which are methods and are called like methods;
> they are not operators.
>

They're methods that have names that are operators, so the proposal treats
them like other functions that have names that are operators.

In Swift 3, there are two types of global functions:
1) Functions with names that are not operators, which have mandatory
argument labels; e.g., `func abs(_ x: Int)`
2) Functions with names that are operators, which mandatorily *lack*
argument labels; e.g., `func +(lhs: Int, rhs: Int)`

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.

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's
indirect) omits the labels.

I can'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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/dedd2459/attachment.html>