[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Matthew Johnson]

As the review of the Flexible Memberwise Initialization proposal draws to a close I would like to offer some final thoughts.  

First, I would like to thank everyone who has reviewed the proposal and participated in the discussion.  You have all given me a lot to think about.  I believe this discussion has been very productive.  It has helped to move my thinking on the topic forward and shape a more complete, more compelling vision of where we can go.

At a high level I think there are a few takeaways.  

First, there seems to be very broad (but not universal) agreement that something should be done to make trivial initialization code more concise.  The problem is worth solving.

Second, there is more support than opposition for this proposal, but the response is definitely mixed.  By my tally the responses are roughly:

55% favorable (Chris and I are both still favorable)
20% mixed
25% opposed

The categorization is somewhat subjective but I believe anyone who does a tally on their own will come up with reasonably similar results.

Third, there are some common and valid criticisms which are addressed further down below.

Finally, I after much vetting I still believe this proposal does a good job of fulfilling the goal it set out to do, namely improve the existing memberwise intializer by making it much more flexible.  

Even several of those who oppose the proposal have agreed with that.  The basis of their opposition is that once you work out the details of doing so the resulting complexity is not worth it.  

Personally, I believe the increase in complexity over the current implicit memberwise initializer is not as significant as some perceive and the additional flexibility more than pays for the cost of the incremental complexity.  The changes from current state can be summarized concisely as:

1. Allow the memberwise initializer to be used in classes
2. Allow default parameter values for `var` properties
3. Fix the problem the current memberwise initializer has with lazy properties
4. Use the `set` rather than `get` visibility for `var` properties
5. Allow you to request the memberwise initializer, including:
	i. Add additional parameters
	ii. include an initializer body
	iii. Specify access level, which will result in omission of memberwise parameters for more-private properties (it would be reasonable to limit this to private and internal if concerns about allowing it to be public are a significant factor)

The perceived complexity of this proposal focuses on the property eligibility rules.  As noted in the list above, there are only two differences in those rules under the curernt proposal compared to the existing implicit memberwise initializer: #4 and #5.iii.  In exchange for accepting those two changes this proposal gives us the increased functionality in the rest of the list.

Despite the proposal doing a good job of fulfilling the basic goal, there have been some very valid critiques of it:

1. **Complexity:** the rules of any workable automatic model are inherently nontrivial.  
2. **Limitations:** it isn't possible to specify an explicit list of parameters, their order, their external lablels, and default values for `let` properties.  
3. **Specificity:** the memberwise initialization is a very special case feature.  It would be better to have more general facilities that support the memberwise initialization use case.

I have been giving a lot of thought to all of them.  I espicially want to thank Dave Abrahams and Joe Groff for starting the discussion around looking for more general facilities to support memberwise initialization. 

Ultimately, improving the existing memberwise initializer is not the best premise for a long-term solution to address the limitations of this proposal.  A solution built on more general features can be just as clear and expressive, while also serving use cases beyond memberwise initialization.

With all of the above in mind, my recommendation is to accept this proposal and simultaneously keep working on more general facilities that can supercede the faciilities of this proposal (aside from the imiplicit memberwise initializer).  I make this recommendation for the following reasons:

1. This proposal improves the implicit memberwise initializer which will not be touched by proposals for more general features adressing.
2. There is no guarantee that more general features addressing memberwise initialization will make it into Swift 3.  Accepting this proposal guarantees we will see improvements that I believe are worthwhile, even if they are not a final solution.
3. Implementation could begin with an eye on the more general approach, possibly providing a head start on implementing them.

I would also like to begin discussion regarding three general facilities that can work together to improve the conciseness and expressiveness of our initializers.  The combination of the first two facilities can supercede the functionality of this proposal.  I believe all three facilities working together can signficantly increase the clarity and expressiveness of our initialization code.  

1. Parameter forwarding: I began working on a general purpose parameter forwarding proposal prior to this review.  This feature will add clarity to various forms of chained initializers.  It will also be to any function that needs to forward a set of arguments from its caller directly to another function, not just to initializers.

2. Partial initializers: The idea for this proposal was inspired by thinking about Joe's example of a more general solution.  Using a setter to perform initialization (especially of `let` properties) just seems wrong to me.  What we need is a partial initializer which can be used to factor out common initialization logic.  Partial initialzers are a general purpose initialization tool, not a tool specific to memberwise initializers.  However, when combined with parameter forwarding and a few implicit partial initializers, it is possible to replace the explicit memberwise initializers described in this proposal with syntax that is just as concise.

3. Property lists: Property lists were inspired by two subthreads of this review.  One was Joe's idea for a computed "members" tuple property.  The other is all of the discussions related to limitations and lack of control in the Flexible Memberwise Initialization proposal.  Property lists are a declaration that allows a user to declare a specific set of properties, in a specific order, with specific labels and specific default parameter values.  This declaration results in a synthesized partial initializer as well as a synthesized computed tuple property.  It may also synthesize other memberwise features in the future as new ideas for them arise.  The property list enables extremely concise yet expressive declarations of memberwise partial initializers.  It is also possible to include several implicit property lists such as `members`, `vars`, `lets`, etc which would be quite similar to some of the ideas discussed in the review thread.

The proposal drafts can be found at the following links:

* Parameter forwarding: https://github.com/anandabits/swift-evolution/blob/parameter-forwarding/proposals/NNNN-parameter-forwarding.md
* Partial initializers: https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md
* Property lists: https://github.com/anandabits/swift-evolution/blob/property-lists/proposals/NNNN-property-lists.md

They contain enough detail about the proposed solution that I believe they are ready for a first round of discussion, however none are complete drafts.  I will be starting a thread for each proposal.  Please move discussion specific to each proposal into its respective thread.

Any discussion pertaining to memberwise intitialization, how these proposals address concerns brought up during the review, how well these proposals together provide a good long-term direction for memberwise intialization, etc can remain in one of the threads about the current proposal.

I want to thank you all again for participating.  I'm very much looking forward to continuing the discussion.

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