[swift-evolution] [pitch] Implementation composition
Nevin Brackett-Rozinsky
nevin.brackettrozinsky at gmail.com
Fri Nov 25 12:06:38 CST 2016
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161125/1745ca09/attachment.html>
More information about the swift-evolution
mailing list