<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">Hello Swift community,<br class=""><br class="">The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md</a><br class=""></blockquote><br class=""><div class="">Here are some long and poorly organized notes from the core team meeting to discuss this feature. Many, many, thanks to Alex Martini for capturing many of these details, but the mess I’ve made of this is not his fault. :-)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">--- Metapoints --- </b></div></div><div class=""><br class=""></div><div class="">First, some meta points that came up from several members of the core team:</div><div class=""><br class=""></div><div class="">- Less is more. Many folks (core team and other community members both) commented that the mere presence of the expansive “future directions” section made the proposal off-putting.</div><div class=""><br class=""></div><div class="">- “Pure sugar” proposals need to have strong justification for their existence since they do not add new capabilities, but they do add new complexity to the language.</div><div class=""><br class=""></div><div class="">- This feature included justification based on the fact that the existing memberwise feature has problems, but some core team folks thought that this wasn’t good enough justification. They commented that perhaps we should just remove the existing memberwise init for structs and call it a day. (others strongly disagreed :-)</div><div class=""><br class=""></div><div class="">- The team wanted to evaluate “all” of the conceivable different approaches to make sure that this approach was the right one in general. I captured notes about some of that discussion below. On the balance, they agree that a variant of this proposal is the right way to go.</div><div class=""><br class=""></div><div class="">- We didn’t have time to bikeshed the fine details of the proposal (e.g. the “memberwise” keyword, the … sigil, etc), just discussing the general semantics and shape of what an acceptable solution would look like.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">MOST SIGNIFICANTLY:</b> there was strong pushback about considering this proposal *at all* right now: this is a pure sugar proposal with a broad design space. It doesn’t have long term ABI implications at all, and we have other serious semantic problems in the language to clean up and address. We can tackle this sort of sugar feature at any time, including in Swift 4. The core team would like to defer talking about this for a couple of months until the other things (property behaviors, resilience, and other big changes) are behind us. We need to focus on the important things, because getting syntactic niceties into Swift 3 but missing on ABI stability would be really unfortunate. We have seriously constrained design and engineering bandwidth. This feedback applies to other pure-sugar proposals as well.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">--- Rationale --- </b></div><div class=""><br class=""></div><div class="">I explained three bits of rationale for why we should tackle this:</div><div class=""><br class=""></div><div class="">1) Our existing feature is half-baked and unsatisfying. This causes me personal angst but, as pointed out above, the simplest solution is to just remove what we have until we can do it right.</div><div class=""><br class=""></div><div class="">2) Memberwise init sugar strongly benefits “POD” types and other “bags of property” types (e.g. “Vec4"), and many of the C struct types that Cocoa has (CGRect etc). In these cases, clients often want to initialize all of the fields explicitly and a memberwise init proposal eliminates this boilerplate. This case is what our existing feature attempts to service.</div><div class=""><br class=""></div><div class="">3) Memberwise init sugar can replace some really common “builder” patterns. These cases often have a bunch of configurable state in a class, where almost all of it has default values, but where clients want to be able to only specify deltas from the default. In the cases where you have a type with a ton of data members, a memberwise init is very very appealing because it eliminates a ton of boilerplate to set up a builder manually, and it also allows the captured state to be immutable (if we allow memberwise init of lets, which Matthew is a huge proponent of). This case can often be a class derived from something else (e.g. a Kit class), explaining the desire to specify super.init, add custom parameters, etc.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">#3 is my distillation/abstraction of many of the arguments that Matthew has made on the list and in the proposal (e.g. his very helpful FontPicker example), but I don’t claim that this captures all of his or any one else’s motivation. This is simply the rationale that the team discussed.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">---</b><b class=""> Common feedback and points </b><b class="">---</b></div><div class=""><b class=""><br class=""></b></div><div class="">Getting to points common to any “memberwise initializer” proposal, the goals of the core team are:</div><div class=""><br class=""></div><div class="">- Provide a predictable model. It was concerning to many people that you could accidentally reorder properties and break a memberwise init without knowing/thinking about it. This directly contravenes the resilience model. API diff’ing tools and “synthesized header” views in Xcode ameliorate this, but don’t totally solve it.</div><div class=""><br class=""></div><div class="">- After discussion, the desire to support memberwise init of let properties was found to be a strong goal. The entire win of providing a builder-like pattern in an init method (vs doing initialize to default and reassign over the value later, C# style) is the immutability benefits.</div><div class=""><br class=""></div><div class="">- We would like for memberwise init to be orthogonal to property behaviors, access control, attributes, and all the other stuff you’d want to do on your properties. Also, ideally, you shouldn’t be limited to what kinds of properties can participate.</div><div class=""><br class=""></div><div class="">- The issues around whether properties with a default value (both let and var) can be replaced by a memberwise init is a really important semantic decision we need to nail down. Many of the proposals include the problem/fact that something like:</div><div class=""><br class=""></div><div class="">class C {</div><div class=""> var x : Int = foo()</div><div class=""><br class=""></div><div class=""> memberwise init(…) {}</div><div class="">}</div><div class=""><br class=""></div><div class="">would not run the foo() side effect when initialized with "C(42)”. Similarly, in a case like:</div><div class=""><br class=""></div><div class="">class C {</div><div class=""><div class=""> let x : Int = 42</div><div class=""> memberwise init(…) {}</div><div class="">}</div></div><div class=""><br class=""></div><div class="">it is still very concerning to people that the apparent axiom that “x is 42” could be violated by a memberwise init. Allowing lets have other implementation issues, such as suddenly making “x” require storage, where it could otherwise be optimized out.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">OTOH, my previous objection about being able to write a memberwise init manually is bogus, since you could write the above out like this:</div><div class=""><br class=""></div><div class=""><div class="">class C {</div><div class=""><div class=""> let x : Int // initial value removed.</div><div class=""> init(x: Int) { self.x = x } // manually written memberwise init.</div><div class=""> init() { x = 42 } // move the inline initial value here.</div><div class="">}</div></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">---</b><b class=""> Approaches discussed </b><b class="">---</b></div></div><div class=""><b class=""><br class=""></b></div><div class="">Here are the rough approaches we discussed, along with pros and cons. For consistency, most of them are modeling the analog of sugarizing an example case like this:</div><div class=""><br class=""></div><div class=""><div class="">class C : Derived { // has base class</div><div class=""> var x: Int // no default value.</div><div class=""> var y = 4.0 // default value</div><div class=""> var z = “foo" // default value</div><div class=""><br class=""></div><div class=""> // has an explicit “q” parameter as well as all the members as parameters.</div><div class=""> init(q: Int, x: Int, y: Double = 4.0, z: String = "foo”) {</div><div class=""> self.x = x </div><div class=""> self.y = y</div><div class=""> self.z = z</div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">I ordered this so that the most promising ones are at the end, to keep you all in suspense :-)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">Approach: C# model<br class=""></b><br class="">As pointed out on the list, we could eliminate the notion of a synthesized memberwise init, and move the complexity to the caller side. C# uses syntax along the lines of:</div><div class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>new Foo(){x=42, y=17.0}</div><div class=""><br class=""></div><div class="">pro) No memberwise initializer concept<br class="">con) Requires all fields to be default initialized, which breaks non-nullable pointers etc.</div><div class="">con) Requires mutability, since you’re initializing, and then overwriting a field.<br class="">con) This specific syntax would be problematic with trailing closures etc.</div></div><div class=""><br class=""></div><div class="">Core team was strongly opposed to this approach.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Approach: Scala (among others) memberwise init as part of class decl</b></div><div class=""><br class=""></div><div class="">This would give us something like this:</div><div class=""><br class=""></div><div class=""><div class="">class C(var x: Int, y: Float = 4.0, var z : String = “foo") : Derived {</div><div class=""> var extra = 4.0 // extra, non-memberwise fields supported.</div><div class=""> init(q: Int, ...) { // all initializers get memberwise stuff added, allows bodies.</div><div class=""> extra = 17</div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div><br class="">pro) Very predictable model, makes it very clear what is subject to memberwise init, and that the order matters</div><div class="">pro) This supports indicating that some fields don’t participate in memberwise init.</div><div class="">pro?) Syntax looks vaguely like the parameter list of the init</div><div class="">con) The syntax isn’t actually parameter list syntax, it is property syntax. You’d want to accept public/private, let/var, behaviors, attributes, and lots of other stuff in there. This would introduce confusion about parameter lists.</div><div class="">con) This is sticking more junk into the class decl, which is already populated with class attributes/modifiers, subclasses/protocols, etc.</div><div class="">con) This means we’ve have two very different ways to declare stored properties in a type.</div><div class=""><br class=""></div><div class=""><div class="">Core team was strongly opposed to this approach.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">Approach: Extract the members from the parameters of an initializer decl</b></div></div><div class=""><b class=""><br class=""></b></div><div class=""><div class="">This would give us something like this:</div><div class=""><br class=""></div><div class=""><div class=""><div class="">class C : Derived {</div><div class=""> // members come from the memberwise init.</div><div class=""> memberwise init(x: Int, y: Double = 4.0, z: String = "foo”) {</div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div>pro) Syntactically very terse.</div><div class="">con) This only supports one memberwise init.</div><div class="">con) Two ways to declare stored properties</div><div class="">con) Conflates the property grammar (behaviors etc) with parameter grammar, many of the same problems as approach right above does.</div><div class=""><br class=""></div><div class="">Core team was strongly opposed to this approach.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">Approach: barely extend our existing model:</b></div><div class=""><br class=""></div><div class="">We could put default values onto our existing memberwise init, and allow you to write "memberwise init(...)” to explicitly request it to be synthesized, but not allow a body. We could bring the existing level of feature to classes.</div><div class=""><br class=""></div><div class="">pro) simple, solves some problems with the existing model.</div><div class="">pro) brings memberwise init to root classes and classes that derive from something with a init() to chain to (e.g. NSObject).</div><div class="">con) doesn’t solve enough of the problem to be worth it</div><div class="">con) feels like we are perpetuating a hack.</div><div class="">con) we’d have to extend this further at some point, this is just kicking the can down the road.</div><div class=""><br class=""></div><div class="">Core team was strongly opposed to this approach. Better to either rip out what we have or do a bigger approach.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class=""><b class="">Approach: Magic “members” tuple (or other </b><b class="">generics/</b><b class="">variadics features) </b></div><div class=""><br class=""></div><div class=""><div class="">class C : Derived {</div><div class=""> var x: Int</div><div class=""> var y = 4.0</div><div class=""> var z = “foo"</div></div><div class=""><br class=""></div><div class=""> init(p : … Members) {</div><div class=""> self.members = p</div><div class=""> }</div><div class=""><br class=""></div><div class=""><div class=""> // compiler synthesizes.</div><div class=""> typealias Members = (Int, Float, String)</div><div class=""> var members : Members { get {..} set {..}}</div><div class="">}</div></div><div class=""><br class=""></div><div class="">pro) seems like a more generally useful feature that could pay for itself in other ways</div><div class="">con) doesn’t work with default values, so it doesn’t solve the builder problem at all (and no, we are not adding default values back to tuple types :-)</div><div class=""><br class=""></div><div class=""><div class="">Core team was strongly opposed to this as an approach for memberwise init, but can always consider doing this for other things if it is motivated by them.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">Approach: Introduce sugar for “self.x = x"</b></div><div class=""><b class=""><br class=""></b></div><div class=""><div class="">David Owens ][ mentioned that perhaps we can go with something simpler, like this (concrete syntax is just a strawman):</div><div class=""><br class=""></div><div class=""><div class=""><div class="">class C : Derived {</div><div class=""> var x: Int</div><div class=""> var y = 4.0</div><div class=""> var z = “foo"</div><div class=""><br class=""></div><div class=""> init(q: Int, self.x, self.y, self.z) { </div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">… where self.x in the parameter list is sugar that says it takes whatever the x property is (incl type and initial value if present), and does "self.x = x” in the body.</div><div class=""><br class=""></div><div class="">pro) Does not require introducing the notion of a memberwise init. Any init could use this.</div></div><div class="">pro) Makes it very clear what members are being initialized and what the API for the init is.</div><div class="">pro) Makes it easy to pick and choose which members you want to make available to clients.</div><div class="">con) This isn’t sweet enough sugar to be worthwhile, particularly for the builder pattern case, which would require lots of boilerplate</div><div class="">con) the self.x syntax is weird and surely can be improved, but anything we came up with would be magic and weird. Making this keyword driven (e.g. "memberwise” at least gives people something to google and lets them know they’re looking at something magic).</div><div class="">con) doesn’t address the problems of replacing the var/let initial values (zapping a side effect in either of them, and breaking ‘let’ axioms).</div><div class=""><br class=""></div><div class="">Core team was weakly opposed to this approach, but agree that something like this could be composed on top of another proposal if that made sense.</div></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">Approach: Introduce sugar for “self.x = x”, and add “memberwise and …"</b></div></div><div class=""><b class=""><br class=""></b></div><div class=""><div class="">Extending David Owens ][’s model a bit, we could keep the behavior he indicates and add memberwise/… to handle cases with default values:</div><div class=""><br class=""></div><div class=""><div class=""><div class="">class C : Derived {</div><div class=""> var x: Int</div><div class=""> var y = 4.0</div><div class=""> var z = “foo"</div><div class=""><br class=""></div><div class=""> memberwise init(q: Int, self.x, ...) { </div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">… where self.x in the parameter list is sugar that says it takes whatever the x property is (incl type and initial value if present), and does "self.x = x” in the body. The presence of memberwise/… would forward all the properties with default values.</div><div class=""><br class=""></div><div class="">pro) Since default values can be provided by a callee in any order, this approach can be made stable against reordering of properties.</div></div><div class="">pro) Compared to the base proposal above, this would be great for the builder pattern case.</div><div class="">con) The POD case still requires you to duplicate all your properties, so this doesn’t really address that use-case.</div><div class="">con) the self.x syntax is weird and surely can be improved, but anything we came up with would be magic and weird.</div><div class=""><div class=""><div class=""><div class="">con) doesn’t address the problems of replacing the var/let initial values (zapping a side effect in either of them, and breaking ‘let’ axioms).</div></div></div></div><div class=""><br class=""></div><div class="">Core team was weakly opposed to this approach.</div></div><div class=""><br class=""></div><div class=""><div class=""><b class=""><br class=""></b></div><div class=""><b class="">Approach: Matthew’s proposal </b><b class="">SE-0018 </b><b class="">(the actual formal proposal :)</b></div></div><div class=""><b class=""><br class=""></b></div><div class=""><div class="">class C : Derived {</div><div class=""> var x: Int</div><div class=""> var y = 4.0</div><div class=""> var z = “foo"</div><div class=""><br class=""></div><div class=""> memberwise init(q: Int, ...) {</div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">pro) Solves the POD case as well as the builder case.</div><div class="">pro) Keeps properties the way they are, composes with behaviors etc.</div><div class="">pro) Supports adding custom parameters to the initializer, supports custom chaining to super.init, etc.</div><div class="">pro) Supports multiple different memberwise inits in a class, e.g. that want to chain to different super.init’s.</div><div class="">pro) Like the clarity of having a keyword on the init, and a sigil in the parameter list saying that something is going on.</div><div class="">unclear) I’m not delving into it here, but the access control aspects were very controversial. We didn’t discuss it fully.</div><div class="">con) compared to the Scala approach, doesn’t handle the ability to opt a member out of memberwise init (we’d need some thing like @nomemberwise) </div><div class="">con) Doesn’t address the problems of replacing the var/let initial values (zapping a side effect in either of them, and breaking ‘let’ axioms).</div><div class="">con) Lots of concerns about unclarity that the order of the properties matter. In a large type, the memberwise init could be “at the end” of the class, after a bunch of other initializers and methods, and the properties could be “up at the top”. It could be very unclear to people that memberwise init is even happening, and changing a property could have surprising effects.</div><div class="">con) Not clear from the memberwise init declaration what the extra parameters are, you have to look at a synthesized header or something.</div><div class=""><br class=""></div><div class=""><div class="">Core team thought this was very close, but the problems were significant enough to think it won’t fly, and suggest pursuing the variant below.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Approach: "Opt-in" version of Matthew’s proposal</b></div><div class=""><br class=""></div><div class="">Matthew has mentioned on list that he likes opt-in models, and after discussion the core team agreed that it is more promising than the base proposal.</div><div class=""><br class=""></div><div class="">In addition to the memberwise declmodifier, *also* introduce a declmodifier on the properties in question. Here I’ll use “mwi” as a strawman for “memberwise initializerable”, but it is obviously not the right thing, and I’m sure it will be replaced with something else brilliant :-)</div><div class=""><br class=""></div><div class="">class C : Derived {</div><div class=""><div class=""> mwi var x: Int</div><div class=""> mwi var y = 4.0</div><div class=""> mwi var z = “foo"</div><div class=""><div class=""> var extra = 4.0 // Doesn’t participate in memberwise inits.</div></div><div class=""><br class=""></div><div class=""> memberwise init(q: Int, ...) {</div><div class=""> // your custom code can go here</div><div class=""> super.init(q)</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class=""><div class="">pro) Solves the POD case as well as the builder case.</div><div class="">pro) Keeps properties the way they are, composes with behaviors etc.</div><div class="">pro) Supports adding custom parameters to the initializer, supports custom chaining to super.init, etc.</div><div class="">pro) Supports multiple different memberwise inits in a class, e.g. that want to chain to different super.init’s.</div><div class="">pro) Like the clarity of having a keyword on the init, and a sigil in the parameter list saying that something is going on.</div><div class="">pro) as with the Scala approach it handles the ability to have members be both memberwise and non-memberwise participating.</div><div class="">pro) Works with let and var initializer semantics.</div><div class="">pro) Looking at a property, you know immediately that it participates in memberwise init, and that you should go update the memberwise inits if you move it or change it. We could warn/error if you have a “mwi” property and no memberwise init, or a memberwise init with no mwi property.</div></div><div class="">pro) because this is an opt-in model, we can eliminate the controversial access control aspect of SE-0018.</div><div class="">con) Not clear from the memberwise init declaration what the extra parameters are, you have to look at a synthesized header or something.</div><div class="">con) more verbose than Matthew’s proposal. OTOH, the verbosity isn’t “boilerplate" since we’re getting something out of it. Simple POD cases can be written as (e.g.) “mwi var x, y, z, w : Double” which isn’t bad.</div><div class=""><br class=""></div><div class="">Adding the modifier on the affected property decls helps improve the intentionality and eliminate some of the "spooky action at a distance" problem, but the major breakthrough (IMO) is that it allows us to include lets into the model, and gives us a simple answer for why side effects are squashed on vars. Consider this example:</div><div class=""><br class=""></div><div class="">class C { </div><div class=""> mwi let a = 42</div><div class=""> mwi var b : Int = sideeffect()</div><div class=""><br class=""></div><div class=""> memberwise init(…) {}</div><div class="">}</div><div class=""><br class=""></div><div class="">A call site would look like this, giving A a value of 75 and would not run the side effect:</div><div class=""> let tmp = C(a: 75, b: 12)</div><div class=""><br class=""></div><div class="">We’re ok with the side effect being squashed, and the let axiom being broken given that there is a decl modifier on the property decl. This is because you can tell locally by looking at the property that a memberwise initializer provides a different value. From an implementation perspective, this is also pretty great, because this leads to a very straight-forward codegen model that cleanly meshes with what we already have.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">--- A path forward --- </b></div></div><div class=""><b class=""><br class=""></b></div><div class="">So that’s where we left it. Coming back to the meta point above though, the core team really doesn’t want to discuss this right now, given that this is purely a sugar proposal and we need to stay focused on the primary Swift 3 goals. If Matthew or another community member wants to pick this up and keep running with it, that is perfectly fine, but we should defer more formal discussion about the proposal until at least march/april-ish. Likewise, other pure sugar proposals should similarly be deferred at this point, unless they have some strong motivation that aligns with a Swift 3 goal. </div><div class=""><br class=""></div><div class="">I want to thank Matthew in particular for passionately pushing this area forward!</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>