<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=""><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=""><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=""><div class="">I deny that, and even if it is true, there is a price to pay — and that is more than the lines of code that are required…</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Personally, I think it is a lot more readable to put members separate lines, but if you don’t like doing that:</div></div></div></div></blockquote><div>You are focusing on the least important thing here — I basically meant to say that the lower line count is no real benefit, but that there are advantages that aren't as easy to spot.</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=""><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=""><blockquote type="cite" class=""><div class="">1. It interacts well with access control</div></blockquote><div class="">Better than Kotlin? Please prove this.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Please look at the examples I have in the Access Control section of the proposal. I spent some time reading the Kotlin docs and it isn’t clear to me that Kotlin can do this. But maybe it can. I don’t know Kotlin well. It sounds like you do, so if it can, please show how this is done in Kotlin.</div></div></div></div></blockquote><div>I actually don't know Kotlin that well — and that contributes to my evaluation of their solution: It is intuitive, and I did not have to read a huge article to understand it.</div><div>What I can see in your example is that the proposed syntax allows me to trigger compiler errors that will never happen with Kotlin (and errors that cannot happen are the ones I like the most).</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=""><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=""><blockquote type="cite" class=""><div class="">2. Partial memberwise initialization is possible</div></blockquote><div class="">The same with Kotlin — and imho at least as easy</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That isn’t clear from the Kotlin docs. It may well be that they are just missing examples. Please post some samples showing how this is handled.</div></div></div></div></blockquote><div>see below; of course, the sample won't use memberwise initialization, but archive the same in a (imho) better way</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=""><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=""><blockquote type="cite" class=""><div class="">3. It allows memberwise initializers to accept non-memberwise parameters to initialize private state</div></blockquote><div class="">I think this can be achieved with less effort using function-like class declaration (afair Joe already gave an example)</div></div></div></div></blockquote><div class=""><br class=""></div>I don’t see either of the examples Joe posted doing this. Here is an example showing what I mean:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal;" class=""><span style="color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">struct</span> S {
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> s: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">String</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">private</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> i: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// user declares:</span>
memberwise <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">init</span>(other: S, <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span>) {
i <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">other.i</span>
}
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// compiler synthesizes (suppressing memberwise initialization for properties with lower visibility):</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">init</span>(other: S, s: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">String</span>) {
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">/* synthesized */</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">self</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span>s <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> s
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// body of the user's initializer remains</span>
i <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> </span><font color="#0086b3" class="">other.i</font><font color="#333333" class="">
}
}</font></pre></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Instead of several examples, I'll use just a single one to illustrate a bunch of points — and I'm leaving out comments on purpose, because I hope to see others participating with their interpretation:</div><div><br class=""></div><div>public class Customer(title: String, private var birthday: NSDate?, public address: String = "n/a"): Person {</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>protected let statusPoints = - birthday?.timeIntervalSinceNow() ?? 0.0</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let constantWithHardToExpressValue: Int</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>lazy var age: Int = dateCalculationIsHard(birthday)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>init {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>constantWithHardToExpressValue = Int(statusPoints) + 1</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>super.init(title: title)</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>public init(titlePrefix: String, titleSuffixObject: Any) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>init(title: titlePrefix + titleSuffixObject.description, birthday: NSDate())</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div>}</div><div><br class=""></div><div>So: Dear reader, please do my job and explain the "pseudo"-source above ;-) — or ask questions if you are just puzzled by it.</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=""><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=""><blockquote type="cite" class=""><div class="">4. More than one memberwise initializer is possible</div></blockquote><div class="">Kotlin has no need for memberwise initializers at all, and I see this as a big advantage</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Please explain how it is an advantage. How does Kotlin handle a case where you have some private state that needs to be initialized internally to protect invariants, but also some members which users can initialize (such as appearance attributes on a UI widget)?</div></div></div></div></blockquote><div>For me, something that is not necessary is always an advantage — because you can simply remove it and have a result that is more elegant and compact.</div><div>Why would you want to add a feature that is not needed? It's just more work for those who actually build it, and it's more work for those who have to learn how to use it.</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=""><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=""><blockquote type="cite" class=""><div class="">5. Memberwise initialization of properties with declaration modifiers, behaviors / delegates is possible</div></blockquote><div class=""><a href="https://kotlinlang.org/docs/reference/delegated-properties.html" class="">https://kotlinlang.org/docs/reference/delegated-properties.html</a></div><div class="">(afaik this is not only possible, it's handled by the current compiler for a long time)</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, I know Kotlin has this feature. It isn’t clear from the docs how initialization of such properties is handled (for example an Observable property). Maybe you can provide some examples of how this works.</div></div></div></div></blockquote><div>No, I can't (well, I accidentally did it partly...) — but I don't see why I should prove the features of a system that actually exists (and where everyone can easily check the behavior):</div><div>I think it's not that presumptuous to assume that the Kotlin-compiler has no flaws which are so fundamental.</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=""><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=""><div class=""><div class="">Afaics there not much room left for the promised additional flexibility… and the problem with default values for constants just doesn't exist in Kotlin at all.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is currently a problem in Swift. I am confident that it can be solved one way or another. I don’t think a solution should be tied to the “type initializer parameter list” syntax.</div></div></div></div></blockquote><div>As I said before:</div><div>There is no need to copy, but there is also no need to discard a working solution without further explanation.</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=""><div class="">If you can clearly demonstrate how Kotlin is superior in a specific area I will give that great consideration. I want this proposal to be the best it can be. However, you’re going to need to do more than just link to the docs which I have already looked at.</div></div></div></div></blockquote><div>I see it from the other direction:</div><div>You have a "theory" (the proposal) and claim it is sound; Kotlin, on the other hand, is real working code!</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=""><div class="">The good news is that as far as I can tell the things you like about what Kotlin is doing are not mutually exclusive with this proposal at all. Think of it this way - this proposal provides a flexible and orthogonal foundation for memberwise initialization. If desired, a future enhancement could easily be developed to provide additional syntactic sugar on top of it. The example Joe posted shows how that might work. </div><div class=""><br class=""></div><div class="">If this proposal is accepted and you want to pursue a proposal for that additional layer of syntactic sugar to get closer to Kotlin syntax I encourage you to do that. The new syntax should be evaluated independently as its own proposal. I would be happy to help show how your desired syntax could be transformed into existing syntax (including the memberwise initialization syntax if this proposal is accepted).</div></div></div></div></blockquote>I guess you really want to see your proposals accepted — and I understand that, as I'm quite sure that you put a huge amount of work into them.</div><div>But a "let's just take my solution and maybe integrate yours laterl"-attitude imho is not the right way:</div><div>If it is used to silence opposers without actually supporting them later, it is wily; and if it is a honest offer, we'll end up with a language that is extrem complicated because it tries to please everyone (and orthogonality would suffer as well).</div><br class=""><div class="">Best regards,</div><div class="">Tino</div></body></html>