[swift-evolution] [Proposal Draft] automatic protocol forwarding

[Matthew Johnson]

> On Dec 29, 2015, at 5:45 PM, Charles Srstka <cocoadev at charlessoft.com> wrote:
> 
> On Dec 29, 2015, at 5:38 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> 
>>> On Dec 29, 2015, at 5:25 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>>> 
>>> Strong +1 on this proposal. I use Objective-C’s forwarding mechanisms quite often in my custom view code, in order to separate the code managing the outer view, the layout of subviews within the view, and business logic into separate classes, all while presenting a single, monolithic interface to the user. The loss of this ability without writing tons of boilerplate is one of the things about Swift that makes me sad.
>>> 
>>> The one thing I’d change is upgrading the partial forwarding synthesis to the original proposal, as that’s a rather important feature IMO.
>>> 
>> 
>> Thanks Charles.  Do you disagree with the reasons I decided not to include partial forwarding in the initial proposal (it is discussed in alternatives considered)?
> 
> I see it in Future Enhancements, but not in Alternatives Considered (unless I’m just missing it). However, my thinking is that this isn’t really that hard to implement; just have the forwarding mechanism forward only methods that aren’t already implemented in the class. This would be similar to the way protocol extensions work, where if you implement the method you get that, but if you don’t implement it, you get the protocol extension’s implementation.
> 

You are right, I included it in that section.  It is definitely something I want to see supported eventually.  I just don’t want it to hold up the initial proposal.  

I also want to make sure any subtleties have been thoroughly considered and addressed before it goes forward.  I understand that it is in some sense similar in some sense to protocol methods with default implementations.  However I think it is actually closer to inheritance (this proposal can in some respects be considered a limited and controlled form of multiple inheritance).  

The author of a protocol understands and intends the default implementations to be just that - defaults.  The author of the type that is forwarded to may have expectations that it receives all calls for all members of a protocol it implements and the implementation may not work correctly or as expected if that does not happen.  IMO, it is important to think about the implications of partial forwarding, limitations that may be necessary, etc.

Despite my caution around partial forwarding, there is one reason that it might make sense to support partial forwarding in the initial proposal.  Specifically, it would be easy to get around the limitation by simply declaring a new protocol that contains only the members you want to forward and use that in your forwarding declaration.  And of course you can also write manual forwarding code.  So a limitation of the automatic forwarding mechanism wouldn’t stop you from doing partial forwarding, it would just make it more annoying.  It might be better to “complete” the design from the start for this reason.  I will definitely give this further thought.

Do you have specific use cases in mind for partial forwarding?  If so, please share them.

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151229/d9295557/attachment.html>