[swift-evolution] [pitch] Implementation composition

[Matthew Johnson]

> On Nov 25, 2016, at 12:06 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Protocol forwarding was discussed on-list near the end of 2015 in the thread “[swift-evolution] [Proposal Draft] automatic protocol forwarding”. Feedback was generally positive, though there were disagreements about whether the forwarder and/or forwardee should have to conform to the protocol. Also, complications regarding Self requirements were brought up.

I was the author of the draft proposal discussed in that thread.  I’m sitting on a second draft which is about 2/3 complete.  I will finish the draft and bring it back up when the core team is ready to consider proposals along these lines again.

The ideas I have run in a different and more general direction than what you suggest below.  But let’s wait until the time is right to dive into the details.

> 
> For simplicity, if we are going to do this, I propose the following:
> 
> Direct forwarding
> • Both the forwarder and the forwardee must conform to the protocol being forwarded.
> • The forwarder’s associated types are inferred to (and must) match the forwardee’s.
> • Requirements the forwarder implements take precedence and are not forwarded.
> 
> Self requirements
> • A return type of Self cannot be forwarded.
> • A return type of, eg. Self.Element, *can* be forwarded, since the associated types match.
> • A parameter type of Self is forwarded in the natural way, by calling the forwardee’s implementation with the argument’s forwardee.
> 
> Example of that last point:
> 
> protocol P { func f(_: Self) }
> struct Q: P { func f(_: Q){ } }
> class C: P {
>   var q: Q implements P
>   
>   // synthesized:
>   func f(_ a: C) {
>     q.f(a.q)
>   }
> }
> 
> Some of these restrictions could potentially be lifted in the future, however for the time being I think they serve an important purpose.
> 
> All that said, I am not yet entirely convinced that protocol forwarding carries sufficient benefits to justify its addition to the language.
> 
> Nevin
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161125/31bea7ff/attachment.html>