Yes I did mess up the translation, that will teach me to do it at night on an iPad (therefore no compiler). The correct translation is:<div><br></div><div>Types and let's needed for example:</div><div><br></div><div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public class SuperType {</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> init(_: SPType) {}</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public struct SPType {}</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public struct PPType {}</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public struct CPType {}</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> let sPInitial = SPType()</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> let pPInitial = PPType()</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> let cPInitial = CPType()</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)">Example:</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div style="margin:0px;line-height:normal"><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public class Ex public init(</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> superParam: SPType = sPInitial, </span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> private label privateParam: PPType = pPInitial, </span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> calculatedParam: CPType = cPInitial</span></font></div><div style="margin:0px;line-height:normal"><span style="background-color:rgba(255,255,255,0);font-size:small"> )</span><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"></span><span style="background-color:rgba(255,255,255,0);font-size:small">: SuperType(superParam)</span><span style="background-color:rgba(255,255,255,0);font-size:small"> {</span></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> var calculatedParam: CPType {</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> get { return CPType() }</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> set {}</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div></div><div style="margin:0px;line-height:normal;min-height:13px"><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div style="margin:0px;line-height:normal;min-height:13px"><font size="2"><span style="background-color:rgba(255,255,255,0)">Would be translated to:</span></font></div><div style="margin:0px;line-height:normal;min-height:13px"><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div style="margin:0px;line-height:normal"><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public class Ex: SuperType {</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> private let privateParam: PPType</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> public init(superParam: SPType = sPInitial, label privateParam: PPType = pPInitial, calculatedParam: CPType = cPInitial) {</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> // 1. Initialize generated stored properties and existing stored properties, but not calculated properties</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> self.privateParam = privateParam</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> // 2. Call super</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> super.init(superParam)</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> // 3. Initialize calculated properties</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> self.calculatedParam = calculatedParam</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> var calculatedParam: CPType {</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> get { return CPType() }</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> set {}</span></font></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div></div><div style="margin:0px;line-height:normal"><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div><br></div><div>You say "<font size="2"><span style="background-color:rgba(255,255,255,0)">There are also several aspects of this translation that are somewhat vague"; without more detail it is difficult to know what you mean, can you elaborate please. The proposal is meant to be equivalent to a textual translation so I was hoping that an example would be sufficient; happy to elaborate if you say what you don't get.</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">You say "Several of these points are also true of my proposal and several others would be true if what I believe are the most important future enhancements are added." Again can you elaborate, difficult to respond without knowing what points and why. I am not trying to be awkward but I am unsure what you mean. As a general note there is a lot in the current proposal that says this could be added in the future, I was responding to the proposal as proposed not what might be added in the future. Also if there are some aspects of the proposal that really need to be added then they should be part of the proposal.</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">Pretty much along the same lines, you say "This is not true. There are additional differences." What additional differences?</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">And again, you say "I disagree. The current proposal clearly states reasons not addressed here.</span></font><span style="background-color:rgba(255,255,255,0);font-size:small">" Can you expand? Obviously I thought I had covered everything otherwise I wouldn't have said that the points are covered. So can you point me in the direction of your concerns?</span></div><br>On Thursday, 7 January 2016, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 6, 2016, at 4:52 PM, Howard Lovatt <<a href="javascript:_e(%7B%7D,'cvml','howard.lovatt@gmail.com');" target="_blank">howard.lovatt@gmail.com</a>> wrote:</div><br><div><font size="2"><span style="background-color:rgba(255,255,255,0)">Here is an expanded proposal for the syntax for a Scala style memberwise syntax and equivalent code, specification is via an example rather than formal syntax since this is easier to follow. Note it is like Scala’s syntax but it is ‘Swiftified” (in particular still retains `init` keyword).<br><br> class Ex public init(<br> superParam: sPType = sPInitial,<br> private label privateParam: pPType = pPInitial,<br> calculatedParam: cPType = cPInitial<br> ): SuperType(superParam) {<br> calculatedParam: cPType {<br> get {…}<br> set {…}<br> }<br> }<br><br>This gets translated to:<br><br> class Ex: SuperType(superParam) { {<br> private privateParam: pPType = pPInitial,<br> public init(superParam: sPType = sPInitial, label privateParam: pPType = pPInitial, calculatedParam: cPType = cPInitial) {<br> // 1. Call super<br> super.init(superParam)<br> // 2. Initialize generated parameters and existing parameters<br> self.privateParame = privateParam<br> self.calculatedParam = calculatedParam<br> }<br> calculatedParam: cPType {<br> get {…}<br> set {…}<br> }<br> }<br></span></font></div></blockquote><div><br></div><div>This translation is not valid Swift for several reasons. There are also several aspects of this translation that are somewhat vague and a detailed design is necessary to evaluate how you envision it working.</div><br><blockquote type="cite"><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br>Because the syntax is so short it is part of this proposal to remove both the current default and memberwise initialisers thus simplifying the language overall (remove two features, add one) and at the same time gain power, which is a rare situation and therefore I would suggest optimal.<br><br>It is also more powerful than the proposed `memberwise init(..)` and/or existing automatic `inits` in the following ways:<br><br>1. Allows `lets` to have a default value.<br>2. Allows other properties including computed properties to have a default value.<br>3. Allows any `super.init` to be called (not restricted to `super.init()`).<br>4. Allows control of which properties participate in the `init` (they are listed in the brackets and are not in a super call and are not an existing property).<br>5. Allows private properties to be initialised.<br>6. Allows properties including private properties to have a label instead of their actual name and hence not expose internals (also allows migration of implementation whilst retaining external interface).<br>7. Allows calls to the generated `init` that don’t specify all members, i.e. for `struct Ex init(i: Int = 0, s: String = “") {}` the following are allowed `Ex()`, `Ex(i: 1)`, `Ex(s: “A”)`, and `Ex(i: 2, s: “B”)`.<br>8. Allows visibility of automatically generated `init` to be controlled.<br>9. Supports property behaviours.<br>10. Does not require a new keyword.<br></span></font></div></blockquote><div><br></div>Several of these points are also true of my proposal and several others would be true if what I believe are the most important future enhancements are added. </div><div><br><blockquote type="cite"><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br>The downsides of the proposal relative to `memberwise init(..)` and/or existing automatic `inits` are:<br><br>1. That people would need to be careful when laying out their code otherwise the first line could become long (a bit of pretty printing solves this).<br>2. Existing structs/classes that have automatically generated inits would need to be refactored, e.g. `CGRect` would become `struct CGRect init(var origin: CGPoint, var size: CGSize) {}` (a migration tool would help here).<br><br>Other than the downsides listed above the proposal does everything the current proposal and current implementation does and more (more also listed above) and is simpler to both explain and implement.<br></span></font></div></blockquote><div><br></div><div>This is not true. There are additional differences. </div><br><blockquote type="cite"><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br>The above more than addresses the reasons given in the current proposal for not using the Scala syntax and demonstrates superiority in many areas. </span></font></div></blockquote><div><br></div><div>I disagree. The current proposal clearly states reasons not addressed here.</div><div><br></div><div>I don’t wish to </div><br><blockquote type="cite"><div><font size="2"><span style="background-color:rgba(255,255,255,0)">However if it were the current proposal or nothing I would go with the current proposal since something is better than nothing.</span></font></div></blockquote><blockquote type="cite"><div><br>On Wednesday, 6 January 2016, Matthew Johnson <<a href="javascript:_e(%7B%7D,'cvml','matthew@anandabits.com');" target="_blank">matthew@anandabits.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 5, 2016, at 12:12 PM, Tino Heth <<a>2th@gmx.de</a>> wrote:</div><br><div><div><br><blockquote type="cite">The “type parameter list” syntax is sugar that could be implemented as a layer on top of the current proposal or could be implemented orthogonally.<br></blockquote>Hi Howard,<br>I've heard this argument before, so I'll repeat my answer as well:<br>Both offers don't make sense, it's either one way or the other (or something completely different).<br></div></div></blockquote><div><br></div><div>I don’t think it’s clear whether both make sense or not. They are not mutually exclusive and are aimed at solving related, but different problems. If we adopt the current proposal, the Kotlin / Scala syntax *might* make sense for some use cases. It would depend upon whether the current proposal is considered too verbose in enough cases or not. This may or may not turn out to be the case.</div><div><br></div><div>The reason my proposal looks the way it does is because there are specific goals it intends to achieve and problems it is intended to solve. These goals and problems are not adequately addressed by the Kotlin / Scala syntax.</div><br><blockquote type="cite"><div><div>If diversity starts here, why not have "const" and "val" beside "let", or allow "fn" and "lambda"?<br><br>@Matthew: Please, if you support something, then say so - using clear words, not phrases like "could be implemented”.<br></div></div></blockquote><br></div><div>This phrasing is plenty clear IMO. I am stating a possibility. I do not have a position on whether or not it is a good idea at the moment.</div><div><br></div><div>I have made some modifications to the proposal over the last few days. These changes have been partly motivated by considering the conversation we have had. You may wish to give it another look. If so, please look here: <a href="https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/0018-flexible-memberwise-initialization.md" target="_blank">https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/0018-flexible-memberwise-initialization.md</a>. There is currently an open PR for the latest change so it is not in the main Swift evolution repo yet.</div><div><br></div><div>The most recent change includes a discussion of why it does not use the Scala / Kotlin syntax. You may not like the choice but I hope you can at least understand the rationale (even if you disagree with it).</div><div><br></div><br></div></blockquote><br><br>-- <br> -- Howard.<br><br>
</div></blockquote></div><br></div></blockquote></div><br><br>-- <br> -- Howard.<br><br>