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)`.
On Tue, Apr 26, 2016 at 13:44 Chris Lattner via swift-evolution < [email protected]> wrote: > > > On Apr 26, 2016, at 11:42 AM, 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. > > 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 > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
