<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><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="">What are those advantages precisely? </div></div></div></div></blockquote><div>subjective: Easier to understand</div><div>objective: Saves keywords/syntax ("…", "memberwise", "@nomemberwise", "required", "convenience", "@default"…)</div><br class=""><blockquote type="cite" 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="">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></div></div></blockquote><div class=""><br class=""></div><div class="">Can you point out what potential compiler errors you are concerned about? Are you referring to the access control example where the compiler does not synthesize initialization of a private member in an internal memberwise initializer and thus requires manual initialization of the private member?</div></div></div></blockquote><div>Exactly.</div><br class=""><blockquote type="cite" 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="">public class Customer(title: String, private var birthday: NSDate?, public address: String = "n/a"): Person {</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protected let statusPoints = - birthday?.timeIntervalSinceNow() ?? 0.0</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let constantWithHardToExpressValue: Int</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>lazy var age: Int = dateCalculationIsHard(birthday)</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>constantWithHardToExpressValue = Int(statusPoints) + 1</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super.init(title: title)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public init(titlePrefix: String, titleSuffixObject: Any) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init(title: titlePrefix + titleSuffixObject.description, birthday: NSDate())</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">So: Dear reader, please do my job and explain the "pseudo"-source above ;-) — or ask questions if you are just puzzled by it.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This must be what you are suggesting for Swift because the example uses NSDate?</div></div></div></blockquote><div>Yes indeed — I'm quite sure Kotlin couldn't compile that ;-).</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is it correct that this class would have the following members in addition to the ones declared in the body? </div></div></div></blockquote><div>Yes (but see below)</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">You used access control modifiers in that parameter list. Would you allow any annotations that are valid for properties that can be initialized (i.e. not lazy, but maybe an observable behavior if Property Behaviors are accepted)?</div></div></div></blockquote><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">let title: String // internal</div><div class="">private var birthday: NSDate?</div><div class="">public let address: String = “n/a”</div><div class=""><br class=""></div><div class="">It actually looks like you pass `title` to super so maybe that isn’t expected to synthesize a member?</div></div></div></blockquote><div>Yes</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""> If that is the case how does the compiler determine which parameters should receive member synthesis? </div></div></div></blockquote><div>It could be inferred, but actually I'd prefer explicit rules (those could be "let x: Int" -> constant, "var…" variable, "x: Int" nothing is synthesized, the parameter is used for the parent initializer or to compute the value of a member that isn't visible)</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">If not, I assume super would not have a `title` member and is doing something else with that argument. Is that what you intend?</div></div></div></blockquote><div>Yes</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is it also correct that all of the following forms would be valid at call sites?</div><div class=""><br class=""></div><div class="">Customer(title: “a title”, birthday: nil)</div><div class="">Customer(title: “a title”, birthday: nil, address: “an address”)</div><div class="">Customer(titlePrefix: “a prefix”, titleSuffixObject: Foo())</div></div></div></blockquote><div>Yes</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">If so, does the initializer used in the first two call examples (the designated / memberwise initializer?) receive the same access control as the type itself since it cannot be specified directly?</div></div></div></blockquote><div>Yes and no:</div><div>Kotlin allows you to limit the visibility of the initializer:</div><div>class Customer private init(...</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is it also correct that the init block that calls super would be invoked regardless of which initializer form is used? When would this block run? Immediately after the memberwise initializer is called? Is it the “body” of the memberwise initializer? </div></div></div></blockquote><div>Yes, that is the idea</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">It would need to run prior to any use of self in the body of `public init(titlePrefix: String, titleSuffixObject: Any)` in order to follow Swift's rules of definitive initialization. </div></div></div></blockquote><div>True, the same as it is now</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is the `public init(titlePrefix: String, titleSuffixObject: Any)` initializer actually a convenience initializer?</div></div></div></blockquote>Yes</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Is it required to call the designated / memberwise initializer before it does anything else? What rules need to be followed to ensure definitive initialization happens? Is this rule applicable to <b class="">all</b> additional initializers the author writes? If it is a convenience initializer maybe it just follows the current rules for those in Swift?</div></div></div></blockquote><div>Yes, everything in this hypothetic model behaves like it does now</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Maybe the memberwise parameters plus the body is the single and only designated initializer for the type? Is that what you’re suggesting?</div></div></div></blockquote><div>It would be possible to allow additional designated initializers, but imho this should at least be discouraged.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">What if the init body needs additional non-memberwise parameters? Is it allowed to specify those?</div></div></div></blockquote><div>Yes</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">If so how is that accomplished?</div></div></div></blockquote><div>See above ("which parameters receive member synthesis")</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">How is the parameter ordering in the final parameter list determined?</div></div></div></blockquote><div>Like in a regular function call.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Would you use the `…` placeholder for the memberwise parameters like the current proposal does?</div></div></div></blockquote><div>No, no need for the dots</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">What happens if another initializer wants to initialize `constantWithHardToExpressValue` to a value different than that in the factored out init block? </div></div></div></blockquote><div>You would have to include the member in the parameter list instead of the class body</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">What if the type needs to support more than one designated initializer? Is that possible?</div></div></div></blockquote><div>Yes (see above)</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Would all designated initializers be required to receive the same set of memberwise parameters? If that isn’t what is required how would the author implement the necessary initializers?</div></div></div></blockquote><div>That would be complicated, and is one reason for discouraging multiple designated initializers (the other reason is the hassle when subclassing)</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">You are suggesting a design we should use for a feature in Swift. I don’t think it is unreasonable to ask how that design would address specific use cases in Swift. It is not enough to point at another language with a similar feature. It is also not enough to just assume the Kotlin model is acceptable without being able to answer how it works in specific use cases.</div></div></div></blockquote><div>I didn't create a real competing proposal — I just pointed out to an existing solution that addresses the problems successfully.</div><div>It's hard to define how a hypothetic feature will interact with other hypothetic features...</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I am taking a nontrivial amount of time to work through this with you and am keeping an open mind during that discussion, but it will require specific details to change my mind.</div></div></div></blockquote><div>I really don't expect to convince you to discard your results — our standpoints and opinions are just very different (in other questions even more than in this one…), and consensus is very unlikely.</div><div>As said before, I have much respect for the labour associated with a proposal, and I hope you see my objections not only as an annoyance, but rather as a opportunity to sharpen your arguments.</div><div>(I personally prefer sound opposition over apathy most of the time).</div><br class=""><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">There a lot of details to work through here. If we are do that we would could analyze the differences of the two approaches. I think that is a fair request. There are definitely some significant differences between them. I will hold off on commenting further until we nail down exactly what it is you would like to see and how it would work.</div></div></div></blockquote></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I am trying to solve a problem for Swift. I am willing to continue working through the Kotlin approach with you so we can understand the details of how it would fit in with Swift. That will allow a fair comparison of the differences between the approaches.</div><div class="">I want to see the problems solved in the best way possible. That is why I am investing time in the proposals and also why I am investing time in exploring the alternative you believe is better. If there is a better approach or a way to improve my proposal I would prefer to identify that now rather than have it accepted as-is.</div><div class="">I was trying to show that the two features are not strictly mutually exclusive as one can be expressed in terms of the other. If you don’t like that approach and think it makes the language too complex I understand that position. I am definitely not trying to just silence you. </div><div class=""><br class=""></div><div class="">Let’s work together to understand in detail the differences in these approaches and their respective advantages and disadvantages. The first step in doing that is getting the design of what you would like to see nailed down further.</div></div></div></blockquote>Relax - no one else seems to care, so apparently I'm just a single lunatic without any support and a ticking end-of-holydays countdown (serious work won't leave much time for fighting lost battles ;-)</div><div>So taking a neutral standpoint, the best advice I could give is to basically ignore myself (taking back my own standpoint as a friend of clear words, I'd appreciate a non-implicit reaction ;-)</div>I still think initialization is already a heavy topic that shouldn't get even more complicated and probably won't change my mind — but I can get my head around anything that has been brought up, and considering the community reaction, the majority will do so at least as well (and those who don't follow the discussion on the list simply will have to deal the results, as it has been before).<div><br class=""></div><div class="">Best regards,</div><div class="">Tino</div></body></html>