[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Chris Lattner]

> On Apr 26, 2016, at 11:42 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
>> 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.
> 
> 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:
> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160404/001650.html
> 
> It is *much* better for type checker performance to have (e.g.):
> 
> func +<T : FloatingPoint>(lhs : T, rhs : T) -> T { return lhs.add(rhs) }
> func +<T : Integer>(lhs : T, rhs : T) -> T { return lhs.add(rhs) }
> 
> 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.

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.

-Chris