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

Matthew Johnson matthew at anandabits.com
Thu Dec 31 09:33:14 CST 2015


> On Dec 31, 2015, at 5:04 AM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> I don’t want this thread to get distracted with memberwise initialization
> Makes sense in general, but Kotlin solves those problems as a whole, and the major benefit of their approach is that everything fits together really fine.
> But I'll skip everything that is not related to forwarding.
> 
>> One approach I considered would look like this:
>> 
>> class Forwarder: P {
>>    // I didn’t like `implements` but didn’t have a better idea before I abandoned this approach
>>    var forwardee: Forwardee implements P 
>> }
> Honestly, I'm can't see the value this discarded variant has for this discussion… you have to pit your proposal against Kotlin if you really want to convince anyone of its superiority.
> 
>> With the memberwise initialization proposal you also have the initializer synthesized automatically.  The only thing it doesn’t do that your Kotlin example does is automatically declare conformance.  This was an intentional design decision because it allows for additional expressivity.  This is addressed in the alternatives considered section of the proposal.  
> Can you be more precise? Kotlin clearly states what a class is doing in its first line, with all expressivity that is necessary by practical means.

What I mean is this.  In the example you gave and the syntax Kotlin uses:

class Forwarder(forwardee: Forwardee): P by forwardee {}

Forwarding is coupled to protocol conformance.  This means I cannot use forwarding without conforming to the protocol that is forwarded.  

Here is a quick example using the syntax of my proposal to demonstrate the difference:

class Forwarder {
  let forwardee: Forwardee
  forward P to forwardee
}

vs

class Forwarder: P {
  let forwardee: Forwardee
  forward P to forwardee
}

In the first example Forwarder does not conform to P.  Forwarding is only used to synthesize the members of P.  I am greatly expanding the motivation section of the proposal and will have examples showing where this is what you want.  The lazy collections section I posted last night includes the first examples where this is the case.

In the second example here Forwarder does conform to P.  The author of Forwarder has the flexibility to specify whether conformance is desired or not.

> 
>> Another difference that is maybe subtle but I think important is that with the approach I considered forwarding is declared in the body of a type or extension which emphasizes the fact that forwarding is an implementation detail, not something users of the type should be concerned with.
> But what is the benefit of this emphasis? No solution requires to make the details visible in the public interface, and the ability to bury an important thing like protocol conformance somewhere in the class implementation is no advantage for me.

Protocol conformance is not buried in the implementation in my solution.  I hope the previous example makes that clear.  What is buried in the implementation is the forwarding declaration which causes the compiler to synthesize forwarding member implementations.  This synthesis is an implementation detail and should not be visible outside the implementation.

> 
>> This approach was abandoned as it leads to problems in expressivity and clarity.  Please see alternatives considered for an elaboration of that.  This is especially true with the new approach to handling Self values that Brent suggested.  That approach requires additional syntax around the forwarding declaration, but adds both clarity and expressiveness.
> I think there is little need to worry about expressiveness for a feature that most potential users will probably never utilize in real code — and I don't think options like not conforming to a protocol that is forwarded is a big win here. It looks to me like you are optimizing for very uncommon cases, and sacrificing ease of use in the situations that are the most common by far.

Like I stated, I am working on adding several examples of how this feature can be used in real code.  Please have a look at the lazy collections example I shared last night.  This example, as well as at least one other coming examples take advantage of the ability to use forwarding without requiring conformance.

As with the memberwise initialization proposal, the syntax you would like to see can easily be added as syntactic sugar on top of the current proposal.  I would not support that as I do not like the syntax Kotlin uses for reasons already stated, but that shouldn’t stop you from pursuing a proposal for it.  Maybe a lot of people would agree with you and it would be accepted.

Matthew

> 
>> It appears to me that you value conciseness very highly.  I do value conciseness but I also value safety, clarity, and expressiveness.  
> No, I value elegance and simplicity  — they often lead to clarity and safety.
> 
>>> Why not simply make this feature syntactic sugar and just auto-generate the forwarding methods?
>> 
>> That is exactly what this proposal does.  Why do you feel it is not doing that?
> you're right, guess I mixed up the proposal with something else; so at least we agree on how it should work ;-)
> 
> I'm not saying Swift has to copy another language, but I doubt that anyone who knows Kotlin would actually consider to drop their solution in favor of what is currently discussed...
> 
> Tino
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151231/1a47a56c/attachment.html>


More information about the swift-evolution mailing list