<div dir="ltr">You'll have to forgive my ignorance on the matter because I'm also not a type checker expert. If compile-time performance concerns are the motivating factor, is it possible to address them in a different way that would not require trampoline code or public interface bloat, like hoisting operators into static protocol methods? Presumably then `lhs + rhs` for two T's conforming to FloatingPoint would map directly to `T.+(_ lhs: T, _ rhs: T)` and the concrete global overloads could still be omitted?<div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 26, 2016 at 11:44 AM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Apr 26, 2016, at 11:42 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>> That seems like a purely syntactic concern that could potentially be addressed in other ways, though. I'm not sure the choice of "duplicate all operators using verbosely-named methods" is the best one for the reasons I mentioned above, and the question of "how do we cleanly unify operators with other protocol requirements?" seems out-of-scope and orthogonal to this proposal.<br>
><br>
> There is a strong motivation for this approach though: we want the type checker to be scalable. John recently wrote an epic piece about why having tons of overloads is a really bad idea:<br>
> <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160404/001650.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160404/001650.html</a><br>
><br>
> It is *much* better for type checker performance to have (e.g.):<br>
><br>
> func +<T : FloatingPoint>(lhs : T, rhs : T) -> T { return lhs.add(rhs) }<br>
> func +<T : Integer>(lhs : T, rhs : T) -> T { return lhs.add(rhs) }<br>
><br>
> Rather than overloads for 4 floating point types, and 8+ integer types. We really need to eliminate all the “expression too complex” classes of issues, and this is an important cause of them.<br>
<br>
Also, sorry for not being explicit about this. I’m not a type checker expert, but I believe that using operator requirements imposes the same load on the type checker as having large overload sets.<br>
<br>
-Chris</blockquote></div>