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

[Brent Royal-Gordon]

> 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

> 	* What is your evaluation of the proposal?

I'm in favor, with one small concern:

> Then, the protocol author is responsible for providing a generic global trampoline operator that is constrained by the protocol type and delegates to the static operator on that type:
> 
> 	func == <T: Equatable>(lhs: T, rhs: T) -> Bool {
> 	  return T.==(lhs, rhs)
> 	}

This trampoline operator, and all of the others in the proposal, appears to be 100% pure boilerplate. Could Swift generate them for us?

(Specifically, I'm suggesting that if protocol P defines a `static func $!(args) -> ret`, Swift should automatically generate a global `func #! <T: P> (args) -> ret`, substituting `T` for any `Self`s among the parameters or return values.)

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Speeding up type inference is a Good Thing™.

> 	* Does this proposal fit well with the feel and direction of Swift?

It *is* a little odd and hacky, particularly on the class side. I'm not saying it's any worse than the status quo, but it doesn't feel like a full solution yet.

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Short of Perl 6's solution, which is to introduce full multimethods into the language, I don't think I've seen much that's better. (Other than the trampoline boilerplate, that is.)

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

-- 
Brent Royal-Gordon
Architechies