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

Douglas Gregor dgregor at apple.com
Mon Jan 11 17:18:13 CST 2016

> On Jan 11, 2016, at 3:09 PM, Janosch Hildebrand <jnosh at jnosh.com> wrote:
>> On 11 Jan 2016, at 07:37, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 	* What is your evaluation of the proposal?
>> It’s a well-considered and well-written proposal. I agree with the semantics of memberwise initializers (+1 to adding a reasonable implicit memberwise initializer for classes, and the ability to use default arguments in that implicit memberwise initializer). However, I would prefer to accept the semantics as improvements to the creation of the implicit memberwise initializer, so it’s a -1 to the “memberwise” specifier and “…” placeholder syntax.
> Since this has been mentioned a few times now I'd like to add that I would support that as well.
> I'm not really sure enough yet as to how the reviews work, so I'll ask here:
> Is it possible for a subset or modified version of a proposal to be accepted or would the proposal be rejected while asking for a reduced/modified follow-up proposal?
> Also are proposals always accepted or rejected, or could a proposal be returned as "needs more work, submit again later" instead of a flat out rejection?

The core team can do any of the above, including accepting subsets of proposals, accepting a proposal with modification, sending a proposal back for revision to come through the process again, etc. In general, we’ll try to do the lowest-overhead thing that makes sense for Swift.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160111/63b60fb3/attachment.html>

More information about the swift-evolution mailing list