[swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Matthew Johnson]

> On Dec 21, 2015, at 7:47 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I have completed a draft of the proposal I have been working on for flexible memberwise initialization.  I am really looking forward to your input and will be refining the proposal based on our discussion.
>> 
>> I am including a current snapshot of the proposal in this message.  I will keep the proposal up to date on Github at this link:
>> 
>> https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md>
> This is a really really interesting approach, I really like it.  Detailed comments below, I’m skipping all the stuff I agree with or have no additional comments on:

Hi Chris, thanks!  I’m really excited to hear that you like it!

Replies to your comments are inline.  I hope you’re willing to entertain on some discussion on some aspects of the proposal that you are not immediately sold on.  :)  I am hoping we can find a way to address the goals they represent even if the eventual solution looks different than the current one.

The examples are definitely not a complete representation of what is described in the detailed design.  I assume they provided sufficient context for your initial feedback.  

> 
>> 
>> Flexible Memberwise Initialization
>> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#replacing-the-current-memberwise-initializer>Replacing the current memberwise initializer
>> 
>> struct S {
>>     let s: String
>>     let i: Int
>> 
>>     // user declares:
>>     memberwise init() {}
> It never occurred to me to allow a body on a memberwise initializer, but you’re right, this is a great feature.  I love how this makes memberwise init behavior a modifier on existing initializers.

Yep, the basis of the idea is that the initializer itself handles any non-trivial work and allows the compiler to generate the trivial boilerplate.  The “flexibile” aspect of the idea is that the type / initializer author has enough control to tell the compiler what is trivial and what is not in a relatively concise manner.
>> Properties with initial values
>> 
>> struct S {
>>     let s: String = "hello"
>>     let i: Int = 42
>> 
>>     // user declares:
>>     memberwise init() {}
>>     // compiler synthesizes:
>>     init(s: String = "hello", i: Int = 42) {
>>         self.s = s
>>         self.i = i
>>     }
>> }
> In the case of let properties, I’m uncomfortable with this behavior and it contradicts our current init rules (the synthesized code isn’t legal).  Please change the example to var properties, and then it’s can fit with the model :-).  

I understand that this is not legal under the current init rules because the compiler currently produces a synthesized initialization of the properties to their initial values at the beginning of the initializer.  I actually don’t like this behavior because it doesn’t allow an initializer body to initialize a let property with an "initial value”.  

I’m pretty sure I’m not alone in this.  People want to use immutable properties with “default values” (I believe this is what most Swift developers are calling what the Swift team refers to as “initial values”) without a requirement that all instances actually have that value.  It was actually pretty surprising to me, and I’m sure to others as well, to discover this limitation.  I actually thought it was a limitation of the current implementation rather than something that was intentionally designed.  I’m surprised to hear otherwise.

IMO it makes more sense that the “initial value” is a default and is only used when necessary - i.e. when the initializer body does not initialize the property directly.  This does not contradict immutability of the property for instances of the type as it is still initialized and never modified afterwards.  If we don’t allow initializers to provide a different value than the “initial value” default and we have a type where that is necessary for some initializers we are forced to omit the “initial value” and duplicate it in all of the initializers that actually need it (either as a parameter default value or as part of a property initialization statement in the body of the initializer).  This seems inflexible and results in duplicated constants in our code which is never a good thing.

The proposal as written includes as part of the synthesis algorithm a modification to the current behavior so that initial value synthesis only happens if a member is not assigned in the post-synthesis initializer body.  It also includes an aside which recommends making this change to the initialization rules applicable to all initializers, not just memberwise initializers.  I consider this to be an improvement that falls in the general category of “flexible initialization”, memberwise or not.

With the modified initialization rules covered in the proposal the synthesized code in the example would be legal.

If you’re still uncomfortable with this behavior and with a change to the init rules allowing initializers to initialize let properties with a value different than the “initial value” specified in the declaration can you elaborate on the rationale?  

> 
> That said, I think the interaction of explicit initializers and memberwise initializers begs discussion.  It would be a much simpler model to only get memberwise parameters for properties without an explicit init.  Have you considered this model, what are the tradeoffs with allowing vars to overwrite them?  Allowing an explicit init to be overwritten by the memberwise initializer seems potentially really confusing, and since you allow explicit arguments on inits, this could always be handled manually if someone really really wanted it.  For example, they could write:
> 
> memberwise init(s : String) {
>   self.s = s
> }
> 
> If they wanted to get the sugar of memberwise inits (presumably for other properties without an explicit init) but still allow one to be overwritten.

Personally, I think there is a lot of value in allowing memberwise initialization for properties that do contain an initial value.  Imagine a hypothetical Swift version of Cocoa Touch.  UILabel might have initial values for text, font, textColor, etc but still want to allow clients to provide memberwise initialization arguments to override the default value.  I think there are many cases like this both in UI code and elsewhere.  

I think the complexity of the model stems from the fact that initialization itself can be rather complex.  It is essential rather than incidental complexity and it must be dealt with somehow - either through boilerplate, through compiler synthesis, through restrictions on desired flexibility, or through punting and requiring users to overwrite default values with assignment after initialization completes.  Obviously this proposal goes pretty far down the path of synthesis.

It is very reasonable to have a discussion about what the right tradeoffs are here.  My hope is that we can achieve flexibility without boilerplate and without causing confusion whenever that is possible.  

I’m definitely interested in hearing more thoughts on this.  What do you think the downsides are of synthesizing memberwise initialization for properties with an “initial value”?  

> 
> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#partial-memberwise-initialization>Partial memberwise initialization
>> 
>> struct S {
>>     let s: String
>>     let i: Int
>> 
>>     // user declares:
>>     memberwise init() {
>>         i = getTheValueForI()
>>     }
>>     // compiler synthesizes (suppressing memberwise initialization for properties assigned in the initializer body):
>>     init(s: String) {
>>         self.s = s
>>         // body of the user's initializer remains
>>         i = getTheValueForI()
>>     }
>> }
> This doesn’t seem like the right behavior to me.  The compiler shouldn’t be in the business of scanning the body of the init to decide what members are explicitly initialized.  I’d suggest that the model simply be that the contents of the {} on a memberwise init get injected right after the memberwise initializations that are done.  This mirrors how properties with default values work.

The model does inject the synthesized memberwise initialization just prior to the body of the initializer.  

As written the proposal does scan the body of the init in order to determine which properties receive memberwise initialization.  The idea here is that it provides additional flexibility as it allows specific initializers to “opt-out” of memberwise initialization synthesis for some properties while receiving it for others.

One alternative to this I think I forgot to include in the alternatives section is to allow the `memberwise` declaration modifier on the initializer to be annotated in some way that prevents memberwise initialization synthesis of some parameters that would otherwise receive it.  What do you think of this approach?  It certainly runs in the direction of Swift’s emphasis on clarity.  

If you like this approach better do you have any ideas on what the syntax might look like?  I think it would be best to provide a list of properties omitted from memberwise init synthesis rather than an opt-in list as that would likely be the shorter list.  I don’t have any great ideas for syntax though.

IMO an important aspect of the “flexible” part of this proposal is that it allows specific initializers to "take control” of initialization of specific properties that may be memberwise intialized by most initializers, while still receiving memberwise initialization of other properties.

> 
> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#lazy-properties-and-incompatible-behaviors>lazy properties and incompatible behaviors
>> 
>> struct S {
>>     let s: String
>>     lazy var i: Int = InitialValueForI()
>> 
>>     // user declares:
>>     memberwise init() {
>>     }
>>     // compiler synthesizes:
>>     init(s: String) {
>>         self.s = s
>>         // compiler does not synthesize initialization for i 
>>         // because it contains a behavior that is incompatible with 
>>         // memberwise initialization
>>     }
>> }
> Yes, this is likely to be subsumed into JoeG’s "behaviors” proposal.  In the meantime, I’d suggest no behavior change for lazy properties.

I don’t think the proposal changes lazy properties.  If it does that was not the intent so please point out how and where and I will make a change.

> 
> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#nomemberwise-properties>@nomemberwise properties
>> 
>> struct S {
>>     let s: String
>>     @nomemberwise let i: Int
>> 
>>     // user declares:
>>     memberwise init(configuration: SomeTypeWithAnIntMember) {
>>         i = configuration.intMember
>>     }
>>     // compiler synthesizes:
>>     init(configuration: SomeTypeWithAnIntMember, s: String) {
>>         self.s = s
>>         i = configuration.intMember
>>     }
>> }
> @nomemberwise is an interesting extension, but since it is a pure extension over the basic model, I’d suggest moving this into a “possible future extensions” section.  The proposal doesn’t need this feature to stand on its own. 

Allowing type authors to restrict memberwise initialization to a subset of properties is an important aspect of “flexible” memberwise initialization IMO.  In my mind, this is about allowing the author of a type to segment properties that are “user configurable” from properties that are implementation details.  

Consider again the example of a Swift implementation of UI widget which would reasonably want to allow memberwise initialization of its appearance related properties but would also has a bunch of properties where memberwise initialization is not the right thing to do.  Authors of the type need a way to prohibit memberwise initialization from happening.  Lower access control would be sufficient to do this sometimes, but not always.

If we include syntax allowing specific initializers to block memberwise initialization of specific properties (as mentioned previously) we could get away without @nomemberwise.  However, that would cause many memberwise initializers that could otherwise avoid an opt-out list to include one.  It would also be less clear because the real intention of the author is that the property should never participate in memberwise initialization at all.

I hope this helps to explain why I consider it pretty important.  I hope we can at least have a discussion about keeping it in the main body of the proposal.

If you are strongly opposed to this I will of course move it.

> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#delegating-and-convenience-initializers>delegating and convenience initializers
>> 
>> struct S {
>>     let s: String = "hello"
>>     let i: Int = 42
>> 
>>     // user declares:
>>     memberwise init() {}
>>     // compiler synthesizes:
>>     init(s: String = "hello", i: Int = 42) {
>>         self.s = s
>>         self.i = i
>>     }
>> 
>>     // user declares:
>>     memberwise init(describable: CustomStringConvertible) {
>>         self.init(s: describable.description)
>>     }
>>     // compiler synthesizes (adding forwarded memberwise parameters):
>>     init(describable: CustomStringConvertible, i: Int = 42) {
>>         self.init(s: describable.description, i: i)
>>     }
>> }
> This example is introducing two things: convenience inits, but also parameter arguments.  For the sake of the proposal, I’d suggest splitting the parameter arguments out to its own discussion.  It isn’t clear to me whether the memberwise initializers should come before explicit arguments or after, and it isn’t clear if we should require the developer to put something in the code to indicate that they exist.  For example, I could imagine a syntax like this:
> 
> memberwise init(…) {}  
> memberwise init(describable: CustomStringConvertible, ...) {
> 
> Where the … serves as a reminder that the init takes a bunch of synthesized arguments as well.

The … placeholder is an interesting idea.  I really like it.  The algorithm in the current proposal always places the memberwise parameters at the end of the parameter list, but just prior to a trailing closure argument if one exists.  This would allow additional flexibility of placement.

> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#subclass-initializers>subclass initializers
>> 
>> class Base {
>>     let baseProperty: String
>> 
>>     // user declares:
>>     memberwise init() {}
>>     // compiler synthesizes:
>>     init(baseProperty: String) {
>>         self.baseProperty = baseProperty
>>     }
>> }
>> 
>> class Derived: Base {
>>     let derivedProperty: Int
>> 
>>     // user declares:
>>     memberwise init() {}
>>     // compiler synthesizes (adding forwarded memberwise parameters):
>>     init(baseProperty: String, derivedProperty: Int) {
>>         self.derivedProperry = derivedProperty
>>         super.init(baseProperty: baseProperty)
>>     }
>> }
> This also seems unclear to me.  We’re generally very concerned about tightly coupling derived classes to their bases (in an API evolution scenario, the two classes may be in different modules owned by different clients).  Further, the base class may have multiple inits, and it wouldn’t be clear which one to get the arguments from.

I know there are a lot of complexities here.  It is certainly possible I am missing some showstoppers, especially related to resilience, etc.

User code would of course need to provide sufficient parameters to disambiguate the call to the base class initializer.

The goal in this section is to enable memberwise initialization to be used in a class hierarchy.  I think UIKit is a good case to consider for the sake of discussion.  In a hypothetical Swift version of UIKit we would want to allow memberwise initialization of appearance attributes regardless of where they are declared in the class hierarchy.  (I would hope a designed-for-Swift UIKit would not rely so heavily on inheritance, but nevertheless I think it makes good case study for discussing flexible memberwise initialization).

The same mechanism that handles inheritance should also be able to handle delegating and convenience initializers.  The idea is to write a delegating or convenience initializer that wraps the non-memberwise portion of a memberwise initializer while still allowing the memberwise initialization to “flow through” and be visible to callers of the delagating / convenience initializer.

I attempted to outline a basic strategy for handling propagation of memeberwise initialization through the inheritance hierarchy as well as other cases of initializer delegation in the detailed design.  It is definitely not complete, almost certainly has flaws and omissions, etc.  I’m hoping we can flesh out the details through community discussion.

I hope you will agree that it is important to support inheritable memberwise initialization and that we do need to address this in some way.

> 
> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#detailed-design>Detailed design
>> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#syntax-changes>Syntax changes
>> 
>> This proposal introduces two new syntactic elements: the memberwise initializer declaration modifier and the @nomemberwise property attribute.
>> 
> As before, I’d suggest splitting @nomemberwise out to a “potential future extensions section”.
> 
>> Algorithm
>> 
>> The steps described in this section will be followed by the compiler when it performs memberwise initialization synthesis. These steps supercede the synthesis of initialization for properties with initial values that exists today.
>> 
>> When the compiler performs memberwise initialization synthesis it will determine the set of properties that are eligible for synthesis that are not directly initialized in the body of the initializer. It will then synthesize parameters for them as well the initialization of them at the beginning of the initializer body.
>> 
> I’d strongly suggest considering a model where properties that have an explicit initializer don’t get a memberwise init.

You’ve said this a couple of times so I assume you have a pretty good reason for it.  I’m not totally clear on the reason though, it simplifies the model.  The current memberwise initializer supports var members with an initial value.  Why do you think we should move away from supporting this?  Can you elaborate further?

> 
> Have you considered whether computed properties make sense to loop into your model?

I’m not sure how a property that isn’t stored would be involved in initialization, memberwise or not.  Am I missing something here?

> 
> Typo "initialzier”.

Thanks!

> 
>> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#objective-c-class-import>Objective-C Class Import
>> 
>> Objective-C frameworks are extremely important to (most) Swift developers. In order to provide the call-site advantages of flexible memberwise initialization to Swift code using Cocoa frameworks this proposal recommends introducing a MEMBERWISE attribute that can be applied to Objective-C properties and initializers.
>> 
> This is also an orthogonal extension on top of the base proposal.  I’d suggest splitting it off to a “possible future extensions” section as well.

This makes sense.  I will do this.

The reason I included this section is that I think most developers would really like some syntactic sugar for configuring instances of Cocoa classes.  Enabling them to work with memberwise initialization seems like a pretty natural way to do this.  But you’re right, this could certainly be a future follow-on proposal once we hash out the details on the Swift side.  


> 
>> 
>>  <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#impact-on-existing-code>Impact on existing code
>> 
>> The changes described in this proposal are strictly additive and will have no impact on existing code.
>> 
>> One possible breaking change which may be desirable to include alongside this proposed solution is to elimintate the existing memberwise initializer for structs and require developers to specifically opt-in to its synthesis by writing memberwise init() {}. A mechanical transformation is possible to generate this declaration automatically if the existing memberwise initializer is removed.
>> 
> I think that that would be very interesting to discuss, but I lean towards keeping our existing model for synthesizing a memberwise init if there is no other init in a struct (and we should do it for classes as well).  Requiring someone to write "memberwise init() {}” is just boilerplate, and producing it as “internal” avoids most of the problems from being something undesirable being generated.  That said, I see the argument that being more explicit is good.

Yeah, I don’t have a strong opinion on this.  I just wanted to point out that making it explicit wouldn’t be too burdensome and it would eliminate any “hidden” initializers.

> 
> Overall, I’m a huge fan of this proposal and the direction you’re going in.
> 
> -Chris
> 


This is really great to hear!  I’m looking forward to continued discussion and refinement. 

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/fa9c9097/attachment.html>