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

[Jordan Rose]

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md <https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md>]

Some comments on Nicola’s points (my own comments to come separately):

> 
> 2) The method signatures in the examples are not up to date with the current
> Swift 3 syntax. For example:
> 
> protocol Equatable {
>  static func ==(lhs: Self, rhs: Self) -> Bool
> }
> 
> should be:
> 
> protocol Equatable {
>  static func ==(_ lhs: Self, _ rhs: Self) -> Bool
> }


Operator functions (and subscript indexes) implicitly have no argument labels today, so this isn’t technically wrong. You can see that there are no labels when you use the functions like, well, functions:

func test(input: Int) { print(input) }
(test)(2) // error: missing argument label 'input:' in call
(+)(2, 3) // okay

It may be worth changing, though.

> 
> 4) I don't agree with the request to limit to static methods for the
> operator implementations.
> I support this for symmetrical binary operators like +, but there are other
> operators like += that seem to work better with members. That is, the
> proposed declaration:
> 
> static func +=(_ lhs: inout Self, _ rhs: Self)
> 
> is more similar to the global += operator definition, but is less clear than:
> 
> mutating func +=(_ rhs: Self)
> 
> this is apparent also at the call site. With the proposed syntax, one would
> need to do:
> 
> func +=<T: Foo>(_ lhs: inout T, _ rhs: T) {
>    T.+=(lhs, rhs)
> }
> 
> while with a member function this would read more naturally as:
> 
> func +=<T: Foo>(_ lhs: inout T, _ rhs: T) {
>    lhs.+=(rhs)
> }

I strongly agree with this for assignment operators, and I also think it’s important for things that make sense to override in a subclass. However, it then puts prefix and postfix operators right back in the space of needing a keyword instead of using argument label.


> 
> 5) the proposal mentions the open question of ambiguities between the dot
> syntax to access methods and operators whose name starts with a dot.
> This seems to be a real issue: I don't think
> 
> return T....(minimum, maximum)
> 
> looks any good, even if the compiler was able to parse it.
> 
> However, this just means that the methods used to implement operators with
> problematic names would need to use different names. Arguably, the only
> cases where one would really want to use methods with operator names is for
> arithmetical operators. Custom operators like ... are better expressed as
> methods with more significant names.

Backtick escaping could help with this as well:

return T.`…`(minimum, maximum)

It’s still not great but it’s at least less of a soup.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160523/b94a0385/attachment.html>