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

[Tony Allevato]

You'll have to forgive my ignorance on the matter because I'm also not a
type checker expert. If compile-time performance concerns are the
motivating factor, is it possible to address them in a different way that
would not require trampoline code or public interface bloat, like hoisting
operators into static protocol methods? Presumably then `lhs + rhs` for two
T's conforming to FloatingPoint would map directly to `T.+(_ lhs: T, _ rhs:
T)` and the concrete global overloads could still be omitted?


On Tue, Apr 26, 2016 at 11:44 AM Chris Lattner <clattner at apple.com> wrote:

>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160426/494cc20d/attachment.html>