<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Dec 29, 2015, at 12:06 PM, Kevin Ballard 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=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The downside to this is it needs to be manually declared for each protocol. But I wager that most protocols actually aren't really amenable to forwarding anyway.</span></div></blockquote></div><br class=""><div class="">At least from a language-mechanics perspective, the only fundamental blocker I can think of that makes a protocol difficult to forward are nontrivial `Self` requirements, since you need a way to map from Foo<Forwarder> to Foo<Forwardee> anywhere the protocol requires Foo<Self>. There's quite a bit of that in the standard library thanks to the collection APIs, to be sure, but I wonder what the breakdown is in the wild for Self-inflicting protocols versus non outside of the stdlib.</div><div class=""><br class=""></div><div class="">I like the idea of using Forwarder protocols with default implementations, since it's amenable to macro generation and doesn't require new language features, but like Matt noted, it's easy to do the wrong thing from an API exposure standpoint by accidentally publishing your type's FooableForwarder conformance when you only wanted to promise that your type was Fooable.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>