[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization
clattner at apple.com
Sun Jan 17 16:02:39 CST 2016
> On Jan 14, 2016, at 6:35 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> I want to thank the core team for putting so much thought and consideration into their feedback. This was clearly given extensive discussion. I also want to appologize if it proved to be a distraction from more important goals.
No need to apologize at all, I was the one getting scolded here, not you :-)
> I agree with the recommendation the team has made. I began to be concerned about the "complexity" of the “automatic" model prior to the start of the review and those concerns proved to be shared by many. Using an "opt-in" approach will provide much-needed clarity. I am especially happy to see that the core team has decided that supporting default parameter values for `let` properties is an important aspect of an eventual solution.
> There is one thing that isn't clear to me in the feedback. Does the core team believe the implicit memberwise initializer should:
> 1) Remain in its current form
> 2) Remain in a slightly enhanced form (i.e. receive default parameter values)
> 3) Remain in an enhanced form and also be extended to classes
> 4) Be removed in favor of making all initilaizers explicitly declared
The core team as a whole didn’t discuss this, but the design that I think makes sense is:
- Extend the current support to root classes and derived classes whose base has a zero-argument init to chain to (e.g. NSObject).
- *Consider* extending the current support to have default values on the parameters. This will be contentious with the core team given the discussion about killing side effects and changing let axioms, etc.
That said, when it comes time to discuss this, I’d suggest just looking at both options and enumerating tradeoffs.
> As requested, I will defer work on a modified formal proposal until the time is right. Chris, please let me know when you're ready to take this topic up again. I will draft a proposal based on the "opt-in" approach (with no future enhancements!).
Sounds great, please feel free to ping the list in the mid to late march timeframe, when hopefully we’ll have most of the big ticket items for swift 3 at least figured out, if not all finished.
> In the meantime, anyone who is interested in seeing an outline of possible options for an "opt-in" approach that builds on more general initialization features should keep an eye out for the second (first complete) draft of my Partial Initializers proposal. At John McCall's request I am including an a section that describes how partial initializers could be related to memberwise intialization. I hope to have the draft ready later today.
> Thank you again to everyone who participated in the discussion and review of my proposal. It has been a very productive conversation. My thinking about the topic has been refined and clarified significantly by this process.
Thank you again for driving this Matthew, I still really want to see this area improved and cleaned up.
More information about the swift-evolution