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

[Tony Allevato]

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