[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols
Chris Lattner
clattner at apple.com
Tue Apr 26 13:42:46 CDT 2016
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.
-Chris
More information about the swift-evolution
mailing list