<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 Dec 29, 2015, at 3:08 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">I have completed a first draft of a proposal to introduce automatic protocol forwarding. I’m looking forward to feedback from everyone!<br class=""></blockquote><br class="">Some things I don't see discussed here:<br class=""><br class="">* Does it have to be a protocol? Why not also allow the concrete type of the property you're forwarding to? Obviously you couldn't form a subtype relationship (unless you could...), but this might be useful to reduce boilerplate when you're proxying something.<br class=""></div></div></blockquote><div><br class=""></div><div>This is addressed in the alternatives considered section. The short answer is that there the direct interface of the concrete type does not contain sufficient information about potential Self parameters to do this well. This information does exist in the protocol declarations. Allowing this information to be specified in concrete interfaces would add enough complexity to the language that I don’t think it is worthwhile. Joe Groff and I discussed this briefly yesterday: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004660.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004660.html</a>.</div><div><br class=""></div><div>What you *can* do is declare a protocol containing the generalized signatures (substituting Self where appropriate) of all of the members of your concrete interface that you wish to be available to forward. That is a one-time protocol declaration that allows you to forward the concrete interface as many times as you wish. It seems like a reasonable tradeoff.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">* Why the method-based conversion syntax for return values, rather than something a little more like a property declaration?<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var number: Int<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>forward IntegerType to number {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>static return(newValue: Int) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>return NumberWrapper(newValue)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>return(newValue: Int) {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>return NumberWrapper(newValue)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""></div></div></blockquote><div><br class=""></div><div>This is actually a really good idea to consider! I didn’t consider something like this mostly because I didn’t think of it. I’m going to seriously consider adopting an approach along these lines.</div><div><br class=""></div><div>One possible advantage of the approach I used is that the initializer may already exist for other reasons and you would not need to do any extra work.</div><div><br class=""></div><div>A big advantage of this approach is that it would work even when you are forwarding different protocols to more than one member with the same type.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">* If you want to keep the method-based syntax, why use the `init(_:)` initializer instead of one specifically for forwarding, like `init(forwardedReturnValue:)`?<br class=""></div></div></blockquote><div><br class=""></div><div>That was a somewhat arbitrary decision I suppose. I also considered having the compiler look for any initializer accepting the correct type regardless of label.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">* If you want to keep the method-based syntax, why do all forwards, even to different members, share the same transformation method? Wouldn't it be better to have, for instance, `init(returnedNumber:)` and `transformedReturnedNumber(_:)`, so that forwards to other properties could use different logic?<br class=""></div></div></blockquote><div><br class=""></div><div>That is a limitation of the approach I used and the proposal disallows you to do such forwarding because of the ambiguity. I am glad you identified a solution to that!</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">* If you want to keep the method-based syntax, would it make sense to instead have an initializer for instance initializers too, and just have it take a second parameter with the instance?<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init(forwardedReturnValue: Int) {...}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init(forwardedReturnValue: Int, from: NumberWrapper) {…}<br class=""></div></div></blockquote><div><br class=""></div><div>Part of the reason the instance method was used is because sometimes the right thing to do might be to mutate and then return self. Using an instance method gives you the flexibility to do that if necessary.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">* Does this mean that a `public forward` declaration would forward `internal` members through synthesized `public` interfaces, if the forwarder and forwardee happened to be in the same module?<br class=""><br class=""><blockquote type="cite" class="">All synthesized members recieve access control modifiers matching the access control modifier applied to the forward declaration.<br class=""></blockquote></div></div></blockquote><div><br class=""></div><div>Yes, if the forwardee had internal visibility and the forwarder was public the forwarder could publicly forward the interface. This is intentional behavior. The forwardee may well be an internal implementation detail while the methods of the protocol are part of the public interface of the forwarder. It is possible to write code that does this manually today.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">* You don't explicitly mention this, but I assume mutating methods work and mutate `self`?<br class=""></div></div></blockquote><div><br class=""></div><div>Mutating methods are something I didn’t think about carefully yet. Thanks for pointing that out! But generally, yes a forwarding implementation of a mutating method would need to mutate the forwardee which is part of self, thus mutating self.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>