<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 30, 2015, at 5:47 AM, Tino Heth &lt;<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Have you looked at how this is handled in Kotlin?</div></div></div></blockquote><div><br class=""></div><div>I hadn’t, but I did look at a paper on a forwarding preprocessor for Java that was called Jaime. &nbsp;The way forwarding is declared is very similar to Kotlin so it may have been a predecessor:&nbsp;<a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.3374&amp;rep=rep1&amp;type=pdf" class="">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.3374&amp;rep=rep1&amp;type=pdf</a></div><div><br class=""></div><div>The initial approach I considered was similar. &nbsp;I show an example following your Kotlin example down below.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Imho Jetbrains solution is quite elegant — especially as it also has a natural answer to another problem ("f<span style="font-family: 'Helvetica Neue';" class="">lexible memberwise initialization"; the whole init process is only a short chapter in the docs).</span></div></div></div></blockquote><div><br class=""></div><div>I don’t want this thread to get distracted with memberwise initialization so please move back to the appropriate thread if you want to discuss further. &nbsp;However, I will briefly respond here.</div><div><br class=""></div><div>Here is Kotlin:</div><div>class&nbsp;Person&nbsp;constructor(firstName:&nbsp;String, lastName: String)&nbsp;{<br class="">}</div><div><br class=""></div><div>Here is Swift under my proposal:</div><div>class Person {</div><div>&nbsp; &nbsp; var firstName: String</div><div>&nbsp; &nbsp; var lastName: String</div><div>&nbsp; &nbsp; // compiler synthesizes memberwise init</div><div>}</div><div><br class=""></div><div>However, my proposal gives you a lot of additional flexibility:</div><div><br class=""></div><div>1. It interacts well with access control</div><div>2. Partial memberwise initialization is possible</div><div>3. It allows memberwise initializers to accept non-memberwise parameters to initialize private state</div><div>4. More than one memberwise initializer is possible</div><div>5. Memberwise initialization of properties with declaration modifiers, behaviors / delegates is possible</div><div><br class=""></div><div>And probably more. &nbsp;My approach was to design a solution that fits into the current Swift language and is orthogonal to other language features as much as possible.</div><div><br class=""></div><div>If you feel Kotlin’s approach is better please respond to the memberwise initialization thread with some examples written in both Kotlin and in Swift using the memberwise initialization feature I am proposing to demonstrate how and why you think it is better.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Of course, their approach is different, but I'd rather copy from the best than accept mediocrity because of the not invented here syndrome.</div></div></div></blockquote><div><br class=""></div><div>Best is a judgement that depends on the criteria you are using to perform the evaluation. &nbsp;If it really is better using criteria appropriate for evaluating new features for Swift then of course that would be the way to go. &nbsp;I would never advocate different for the sake of different or NIH.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">[short explanation: In Kotlin, we would have</div><div class="">class Forwarder(forwardee: Forwardee): P by forwardee {</div><div class="">…</div><div class="">}</div><div class="">forwardee would be available as a member, and because it is introduced before the protocol conformance, it can be used there without irritation.</div><div class="">Bonus: The designated initializer is defined at the same time.</div><div class="">]</div></div></div></blockquote><div><br class=""></div><div>One approach I considered would look like this:</div><div><br class=""></div><div>class Forwarder: P {</div><div>&nbsp; &nbsp; // I didn’t like `implements` but didn’t have a better idea before I abandoned this approach</div><div>&nbsp; &nbsp; var forwardee: Forwardee implements P&nbsp;</div><div>}</div><div><br class=""></div><div>With the memberwise initialization proposal you also have the initializer synthesized automatically. &nbsp;The only thing it doesn’t do that your Kotlin example does is automatically declare conformance. &nbsp;This was an intentional design decision because it allows for additional expressivity. &nbsp;This is addressed in the alternatives considered section of the proposal. &nbsp;</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>This approach was abandoned as it leads to problems in expressivity and clarity. &nbsp;Please see alternatives considered for an elaboration of that. &nbsp;This is especially true with the new approach to handling Self values that Brent suggested. &nbsp;That approach requires additional syntax around the forwarding declaration, but adds both clarity and expressiveness.</div><div><br class=""></div><div>It appears to me that you value conciseness very highly. &nbsp;I do value conciseness but I also value safety, clarity, and expressiveness. &nbsp;</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div>As for the implementation:<div class="">Why not simply make this feature syntactic sugar and just auto-generate the forwarding methods?</div></div></div></blockquote><br class=""></div><div>That is exactly what this proposal does. &nbsp;Why do you feel it is not doing that?</div><br class=""></body></html>