<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jul 7, 2016 at 11:37 AM Daniel Resnick via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">What is your evaluation of the proposal?<br></blockquote><div>+1<br> <br></div></div><div dir="ltr"><div class="gmail_extra"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div>Yes, the current situation of defining a protocol required operator function globally is potentially confusing and feels inconsistent.<br> <br></div></div></div><div dir="ltr"><div class="gmail_extra"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Does this proposal fit well with the feel and direction of Swift?<br></blockquote></div></div><div dir="ltr"><div class="gmail_extra"><div>Yup.<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote></div></div><div dir="ltr"><div class="gmail_extra"><div>A reading.<br><br></div><div>One thing that's not completely clear to me: if you implement the operator function as a class method and override it in a subclass, in what situation would the overridden version be called? <br></div></div></div></blockquote><div><br></div><div>(Using a binary operator as an example) Since the signature of the operator is (Self, Self), you would have a situation like the following:</div><div><br></div><div>protocol Equatable {</div><div> static func ==(lhs: Self, rhs: Self) -> Bool</div><div>}</div><div><br></div><div>class A: Equatable {</div><div> class func ==(lhs: A, rhs: A) -> Bool { ... }</div><div>}</div><div><br></div><div>class B: A {</div><div> class func ==(lhs: B, rhs: B) -> Bool { ... }</div><div>}</div><div><br></div><div>There is actually no overriding happening here, because the argument types are different.</div><div><br></div><div>So,</div><div><br></div><div> let a = A()</div><div> let b = B()</div><div> let b_as_a: A = B()</div><div><br></div><div> b == B() // should call B.==</div><div> a == B() // should call A.==, because the only match is by upcasting B to A</div><div> b == b_as_a // should call A.==, because the dispatch is done statically</div><div><br></div><div>The latter of those may seem surprising, but it's not a regression—the current global operators would do the same (and Swift would need multiple-dispatch to solve this).</div><div><br></div><div>That being said, it's likely that you would want to be able to call A's == implementation as part of B's. And it just occurs to me that we don't need to support "super" to do this—the solution is rather elegant:</div><div><br></div><div> class func ==(lhs: B, rhs: B) -> Bool {</div><div><span style="line-height:1.5"> guard lhs as A == rhs as A else {</span><br></div><div> return false</div><div> }</div><div> return lhs.someOtherProperty == rhs.someOtherProperty</div><div> }</div><div><br></div><div>By explicitly casting the arguments to their superclass, the operator type dispatch (which is based on the static types of the arguments) will call the correct implementation.</div><div><br></div><div> </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></div></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div></div>