on Wed Apr 27 2016, Tony Allevato <allevato-AT-google.com> wrote: > On Wed, Apr 27, 2016 at 1:14 PM Dave Abrahams <[email protected]> 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 > > > [email protected] > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- > > Dave > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > -- > Dave > -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
