<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 25, 2016, at 12:06 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.</div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">For simplicity, if we are going to do this, I propose the following:</div><div class=""><br class=""></div><div class=""><b class="">Direct forwarding</b></div><div class="">• Both the forwarder and the forwardee must conform to the protocol being forwarded.</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">• The forwarder’s associated types are inferred to (and must) match the forwardee’s.</div><div class="">• Requirements the forwarder implements take precedence and are not forwarded.</div><div class=""><br class=""></div><div class=""><b class="">Self requirements</b></div><div class="">• A return type of Self cannot be forwarded.<br class=""></div><div class="">• A return type of, eg. Self.Element, *can* be forwarded, since the associated types match.</div><div class="">• A parameter type of Self is forwarded in the natural way, by calling the forwardee’s implementation with the argument’s forwardee.</div><div class=""><br class=""></div><div class="">Example of that last point:</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">protocol P { func f(_: Self) }</font></div><div class=""><div class=""><font face="monospace, monospace" class="">struct Q: P { func f(_: Q){ } }</font></div><div class=""><font face="monospace, monospace" class="">class C: P {</font></div><div class=""><font face="monospace, monospace" class=""> var q: Q implements P</font></div><div class=""><font face="monospace, monospace" class=""> </font></div><div class=""><font face="monospace, monospace" class=""> // synthesized:</font></div><div class=""><font face="monospace, monospace" class=""> func f(_ a: C) {</font></div><div class=""><font face="monospace, monospace" class=""> q.f(a.q)</font></div><div class=""><font face="monospace, monospace" class=""> }</font></div><div class=""><font face="monospace, monospace" class="">}</font></div><div class=""><br class=""></div><div class="">Some of these restrictions could potentially be lifted in the future, however for the time being I think they serve an important purpose.</div><div class=""><br class=""></div><div class="">All that said, I am not yet entirely convinced that protocol forwarding carries sufficient benefits to justify its addition to the language.</div><div class=""><br class=""></div><div class="">Nevin</div></div><div class=""><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>