[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[plx]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution