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