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

[Tony Allevato]

On Tue, May 17, 2016 at 9:03 PM Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:


> 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.)
>

That was actually part of the original write-up :)  You can see the removed
content from the diff here:
https://github.com/apple/swift-evolution/pull/283/commits/841514fbd7d11ce1ab6dad8ee3c6473d6c550789

The core team felt that auto-generating the trampolines was too ambitious
for the Swift 3 timeline but that the rest of the improvements should not
be held up by it. I definitely intend to propose auto-trampolines as a
natural follow-up proposal to this (assuming it's accepted) for Swift 3.x/4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/f2bc0299/attachment.html>