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

[Dave Abrahams]

on Wed Apr 27 2016, Tony Allevato <allevato-AT-google.com> wrote:

> On Wed, Apr 27, 2016 at 1:14 PM Dave Abrahams <dabrahams at apple.com> wrote:
>
>     The one possible alternative I thought of would be to support infix
>     notation, e.g.
>
>     x T.+= y
>
>     It might come down to what's easier to parse.
>
> That personally looks a bit awkward to me, but if it turned out to be
> significantly easier from a parsing point of view, I wouldn't object.
>
>     > In this case, the compiler would automatically generate the global
>     > trampoline operator:
>     >
>     > func += <T: TheProtocol>(lhs: inout T, rhs: T) { T.+=(&x, y) }
>
>     Whoops: I didn't realize you were talking about doing that
>     automatically. IMO the minimal change that could possibly fit in Swift
>     3 would be to allow static operator declarations and calls, and have the
>     library declare the trampolines. If there's time to go further, I
>     wouldn't necessarily be opposed, but at this point it's extremely late
>     to do anything ambitious.
>
> That's a reasonable compromise. My thinking was that it would be helpful for the
> compiler to provide the trampoline implicitly for protocol operators because
> it's likely to always be the same delegation, but since they can be written
> manually in 1–2 lines of code, that's not a significant burden.
>
> As you say, if making the operators themselves static is doable in the Swift 3
> timeframe, a longer-term plan could auto-define the trampolines and the compiler
> could either (1) flag ones identical to the would-be-auto-generated ones with a
> warning that they're redundant, or (2) silently accept them. (If we
> autogenerate, then we also have an open question: what do we do if the user
> declares their own trampoline that differs from the expectation? Do we let them
> override?)
>
>     Keep in mind though that several people in the community have long held
>     that operators should be regular members, which presumably would
>     obsolete these static members. On the other hand, we don't have a
>     design for that change, which I think would require defining a new set
>     of lookup rules. This is probably an incremental step in the right
>     direction.
>
> My "regular members", do you mean that `a + b` would become something like `a.+
> (b)`? (Sorry, I'm entering some discussions late here.) 

Not changing the calling syntax, but changing how they're declared (in
the body of one of the participating types, without `static`) and
something-that-has-yet-to-be-designed about how they're looked up.

> I personally don't have a *strong* opposition to that, but I feel like
> arbitrarily elevating the left-hand side to be a receiver instead of
> an argument doesn't buy you much either. 

Hey, I agree.  I've never quite seen how this “regular members” plan is
going to work out.  Python and D do something for this that involves
awkward fallbacks to "r" versions of the operators for heterogeneous
argument types.  I don't know that I'd want to repeat that in Swift.
Maybe your static-with-automatic-trampoline scheme is actually a better
long-term solution.  But we don't have time to design the long-term
solution right now ;-)

> To me, `a + b` is computing a result based on two values on equal
> footing, not calling a method on one and passing it the other. And
> since class methods permit the "static" protocol method to be
> dispatched dynamically, it doesn't need to be a method for that reason
> either if you're implementing operators on a class hierarchy.
>
>     > Users could still refer to `T.+=` directly to obtain a reference to the
>     `(inout
>     > T, T) -> Void` function, but would likely only need to do this in the
>     context of
>     > generic algorithms, and then only in situations where the compiler needed
>     more
>     > help inferring the argument types (if `+=` by itself didn't provide enough
>     > context).
>     >
>     > >
>     > >
>     > > – Steve
>     > >
>     > > _______________________________________________
>     > > swift-evolution mailing list
>     > > swift-evolution at swift.org
>     > > https://lists.swift.org/mailman/listinfo/swift-evolution
>     >
>     > --
>     > Dave
>     >
>     > _______________________________________________
>     > swift-evolution mailing list
>     > swift-evolution at swift.org
>     > https://lists.swift.org/mailman/listinfo/swift-evolution
>     >
>
>     --
>     Dave
>

-- 
Dave