<div style="white-space:pre-wrap">If this design is a workaround for type checker limitations, then perhaps comparison method names are better prefixed with an underscore and/or using abbreviated terms-of-art (eq, lt, lte, etc.)? As Tony points out, it seems tragic to promote to an equal footing with `2.0 + 2.0 == 4.0` the alternative form `(2.0).adding(2.0).isEqual(to: 4.0)`.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 26, 2016 at 13:44 Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On Apr 26, 2016, at 11:42 AM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt; That seems like a purely syntactic concern that could potentially be addressed in other ways, though. I&#39;m not sure the choice of &quot;duplicate all operators using verbosely-named methods&quot; is the best one for the reasons I mentioned above, and the question of &quot;how do we cleanly unify operators with other protocol requirements?&quot; seems out-of-scope and orthogonal to this proposal.<br>
&gt;<br>
&gt; 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>
&gt; <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>
&gt;<br>
&gt; It is *much* better for type checker performance to have (e.g.):<br>
&gt;<br>
&gt; func +&lt;T : FloatingPoint&gt;(lhs : T, rhs : T) -&gt; T { return lhs.add(rhs) }<br>
&gt; func +&lt;T : Integer&gt;(lhs : T, rhs : T) -&gt; T { return lhs.add(rhs) }<br>
&gt;<br>
&gt; 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<br>
_______________________________________________<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>