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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
