> On Apr 27, 2016, at 9:10 AM, Jordan Rose <[email protected]> wrote: > > >> On Apr 26, 2016, at 11:42, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> On Apr 26, 2016, at 8:47 AM, Tony Allevato via swift-evolution >> <[email protected]> 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. > > That’s a reason to pull operators in as members, not push them out as > second-class free functions.
There are a ton of open questions that would have to be resolved, but I agree that in theory that could resolve the issue as well. The practical problem is that those issues won’t get resolved in the Swift 3 cycle, and yet we still want improved numeric protocols, compile time, and decent overload failure diagnostics. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
