<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 class="">
<div class="">-Dave</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 7:33 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Dec 31, 2015, at 5:04 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">I don’t want this thread to get distracted with memberwise initialization<br class=""></blockquote>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.<br class="">But I'll skip everything that is not related to forwarding.<br class=""><br class=""><blockquote type="cite" class="">One approach I considered would look like this:<br class=""><br class="">class Forwarder: P {<br class=""> // I didn’t like `implements` but didn’t have a better idea before I abandoned this approach<br class=""> var forwardee: Forwardee implements P<span class="Apple-converted-space"> </span><br class="">}<br class=""></blockquote>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.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">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. <br class=""></blockquote>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.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">What I mean is this. In the example you gave and the syntax Kotlin uses:</div><div class=""><br class=""></div><div class="">class Forwarder(forwardee: Forwardee):<span class="Apple-converted-space"> </span><b class="">P by forwardee</b><span class="Apple-converted-space"> </span>{}</div><div class=""><br class=""></div><div class="">Forwarding is coupled to protocol conformance. This means I cannot use forwarding without conforming to the protocol that is forwarded. </div><div class=""><br class=""></div><div class="">Here is a quick example using the syntax of my proposal to demonstrate the difference:</div><div class=""><br class=""></div><div class="">class Forwarder {</div><div class=""> let forwardee: Forwardee</div><div class=""> forward P to forwardee</div><div class="">}</div><div class=""><br class=""></div><div class="">vs</div><div class=""><br class=""></div><div class=""><div class="">class Forwarder: P {</div><div class=""> let forwardee: Forwardee</div><div class=""> forward P to forwardee</div><div class="">}</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div>There are ways to handle that, including factoring the APIs of interest out of P and into a private protocol Q, then declaring the Forwardee’s conformance to Q. Now, there’s an expressivity problem with our current access control system that you can’t use an internal or private protocol to provide public API, but that should be fixed separately.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote>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.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Protocol conformance is not buried in the implementation in my solution. I hope the previous example makes that clear. What<span class="Apple-converted-space"> </span><b class="">is</b> 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<span class="Apple-converted-space"> </span><b class="">not</b> be visible outside the implementation.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote>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.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">It appears to me that you value conciseness very highly. I do value conciseness but I also value safety, clarity, and expressiveness. <br class=""></blockquote>No, I value elegance and simplicity — they often lead to clarity and safety.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Why not simply make this feature syntactic sugar and just auto-generate the forwarding methods?<br class=""></blockquote><br class="">That is exactly what this proposal does. Why do you feel it is not doing that?<br class=""></blockquote>you're right, guess I mixed up the proposal with something else; so at least we agree on how it should work ;-)<br class=""><br class="">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...<br class=""><br class="">Tino<br class=""><br class=""></div></div></blockquote></div><br class="" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=JfMPa-2F7wwZPzsZ3QKA8NjtONIYX4SjbWuUxtpfsTY2jc73j3MLQkAv6HwzbAdik0iwLTTmL7so7Q2VgA-2B5CYwXXQ2iMcbHrhe71klOSbLwbBJQrEqzBoEd0ez-2FQRFJ3tZfNVx-2FYIsHEN3Q28AGznhpuMDhjO-2BP76umICzJX0uNq3rMCwM92VLkDUCEyAPgdC0BOpBBPLthrf2-2BfeMt6uCMMluHR79Fk5R6w7S3Zfvf4-3D" alt="" width="1" height="1" border="0" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span></span><span style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: AvenirNext-Medium; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>