Mixed; there are very good ideas here but combined in IMHO some questionably-strict ways. I understand that starting small and extending later is preferable, and I understand the Swift 3 situation.
In favor of these: - allowing static methods to have “operator names” - deprecating operator requirements in protocols - providing default operator definitions as trampolines to the static methods It’s really not clear to me if this is anything more than just: - adding the ability to give (static/class) methods operator names - removing the ability for protocols to declare operators - make all operator implementations “explicit"… - ...but providing “protocol operators” generically (e.g. via suitable “trampolines”) …if that’s all there is to this, I’m ok with it for now, but have a suggestion: I’d *prefer* there be an explicit annotation, e.g. to straw-man it a bit, something like one of these: @trampolined static func +(lhs: Self, rhs: Self) -> Self @trampolined(operator) static func +(lhs: Self, rhs: Self) -> Self …which for now would just produce a compiler warning if no corresponding operator function is defined, but could someday be used to trigger trampoline synthesis. The reason I request explicit syntax for this is b/c it seems *highly* likely that a subsequent enhancement will be to allow a similar mechanism to specify functions like `abs` and `sin` should be similarly trampolined (in their case into free functions); it’d be nice to have a common mechanism for them now, even if their implementation is to be deferred. That said, it’d *concern me* if this proposal somehow planned to enforce that “operators” *always* call through to the operator-named function; it ought to be possible to e.g. define operators like so: protocol AngularCoordinateProtocol { associatedtype Rotation: RotationProtocol static func rotated(angle angle: Self, by rotation: Self.Rotation) -> Self } func +<A:AngularCoordinateProtocol>(lhs: A, rhs: A.Rotation) -> A { return A.rotated(angle: lhs, by: rhs) } func -<A:AngularCoordinateProtocol>(lhs: A, rhs: A.Rotation) -> A { return A.rotated(angle: lhs, by: -rhs) } …and it seems like this proposal wouldn’t preclude that, but I’m not 100% I understand it on that point. Also, I can’t say I’m a fan of having the prefix/postfix handled by argument labels. How hard would it be to e.g. simply allow something like this: func ==<T:Equatable>(lhs: T, rhs: T) -> Bool { return lhs T.== rhs } …instead of the `T.==(lhs,rhs)` syntax? > On May 17, 2016, at 10:33 PM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of "SE-0091: Improving operator requirements in protocols" begins > now and runs through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > > or, if you would like to keep your feedback private, directly to the review > manager. > > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your > review: > > * What is your evaluation of the proposal? > * Is the problem being addressed significant enough to warrant a change > to Swift? > * Does this proposal fit well with the feel and direction of Swift? > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris Lattner > Review Manager > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution