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

Tony Allevato allevato at google.com
Wed May 18 09:08:39 CDT 2016

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:

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>

More information about the swift-evolution mailing list