<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=""><div class="">[Proposal: <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 class=""><br class=""></div>Some comments on Nicola’s points (my own comments to come separately):<div class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">2) The method signatures in the examples are not up to date with the current<br class="">Swift 3 syntax. For example:<br class=""><br class="">protocol Equatable {<br class=""> static func ==(lhs: Self, rhs: Self) -> Bool<br class="">}<br class=""><br class="">should be:<br class=""><br class="">protocol Equatable {<br class=""> static func ==(_ lhs: Self, _ rhs: Self) -> Bool<br class="">}<br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div>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:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div>func test(input: Int) { print(input) }</div></div><div class=""><div>(test)(2)<i class=""> // error: missing argument label 'input:' in call</i></div></div><div class=""><div><div>(+)(2, 3) <i class="">// okay</i></div></div></div></blockquote><div class=""><div><div class=""><br class=""></div><div class="">It may be worth changing, though.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">4) I don't agree with the request to limit to static methods for the<br class="">operator implementations.<br class="">I support this for symmetrical binary operators like +, but there are other<br class="">operators like += that seem to work better with members. That is, the<br class="">proposed declaration:<br class=""><br class="">static func +=(_ lhs: inout Self, _ rhs: Self)<br class=""><br class="">is more similar to the global += operator definition, but is less clear than:<br class=""><br class="">mutating func +=(_ rhs: Self)<br class=""><br class="">this is apparent also at the call site. With the proposed syntax, one would<br class="">need to do:<br class=""><br class="">func +=<T: Foo>(_ lhs: inout T, _ rhs: T) {<br class=""> T.+=(lhs, rhs)<br class="">}<br class=""><br class="">while with a member function this would read more naturally as:<br class=""><br class="">func +=<T: Foo>(_ lhs: inout T, _ rhs: T) {<br class=""> lhs.+=(rhs)<br class="">}<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">5) the proposal mentions the open question of ambiguities between the dot<br class="">syntax to access methods and operators whose name starts with a dot.<br class="">This seems to be a real issue: I don't think<br class=""><br class="">return T....(minimum, maximum)<br class=""><br class="">looks any good, even if the compiler was able to parse it.<br class=""><br class="">However, this just means that the methods used to implement operators with<br class="">problematic names would need to use different names. Arguably, the only<br class="">cases where one would really want to use methods with operator names is for<br class="">arithmetical operators. Custom operators like ... are better expressed as<br class="">methods with more significant names.<br class=""></div></div></blockquote><div><br class=""></div><div>Backtick escaping could help with this as well:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div>return T.`…`(minimum, maximum)</div></div></blockquote><div class=""><br class=""></div>It’s still not great but it’s at least less of a soup.<br class=""><div class=""><br class=""></div><div class="">Jordan</div></div></body></html>