[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