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

Fri Jan 8 17:53:57 CST 2016

> On Jan 8, 2016, at 5:18 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Hi, Matthew. (Hi, everyone.) Thanks for putting together a detailed and well-thought-out proposal. I had some smaller comments:

Hi Jordan, thanks for your review. 

> 
> - Given that these initializers are based on access control, is "public memberwise init(...)" different from "internal memberwise init(...)"? Can I put both in the same type?

If you have at least one internal property they would result in different signatures so would not be a duplicate declaration.  The public memberwise init would obviously need to initialize the internal property somehow.

> 
> - Why not just put the "memberwise" in the parameter list, and drop the decl modifier? This came up in the draft discussion but I didn't see any follow-up.

Good question.  The decl modifier was initially Chris’s idea and it seemed reasonable to me so I ran with it.

> 
> - I kind of agree now that "memberwise" is the wrong name, but I don't have a better one.

It is a bit verbose, and in many ways has the same issues as `associatedtype`.  I used it because it is the terminology in use in Swift today and also don’t have anything better to replace it with.

> 
> …but after reading through the formal review discussion, I have to say I don't think this is a good feature for Swift. I tend to agree with David Owens and others that this is too much magic in one keyword. (I picked David because I think his responses most closely match my concerns out of the dissenters.)
> 
> Imagine trying to explain this feature in The Swift Programming Language. It starts off very simple with the perfect use case:
> 
> public struct Point {
>   public var x: Double
>   public var y: Double
>   public memberwise init(...) {}
> }
> 
> …but then spends the rest of the chapter going over everything in the proposal: why you can't provide a default for 'let' properties, why hiding a setter affects the presence of a member, and what to do if you want to change it but preserve backwards binary compatibility. It seems like a big, complicated feature that "does what you mean" only when it's first added and then becomes an impediment to any later change.

I can certainly sympathize with this.  It is the big drawback of the automatic model.  At the same time, this proposal builds on the existing memberwise init for structs and doesn’t really make the rules that much more complex.  But it does make the feature more prevalent and visible, thus making it more important to understand the rules.  And of course it could be argued that the current memberwise init is too complex as it is.

For the record, here is a concise list of how this proposal expands the current memberwise init:

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)

I am curious to hear your thoughts on which of these points are not desirable, and what your opinion is about the existing rules for the implicit memberwise init for structs.

> 
> I'm motivated to solve the tiny value struct case, the public C-like struct case, but I don't think I want this creeping into the interface of a public class. I'd rather go with the "annotation on parameters" solution (which would be a separate proposal, of course).
> 
> public struct Point {
>   public var x: Double
>   public var y: Double
>   public init(self x: Double, self y: Double) {}
> }
> 
> or
> 
>   public init(@assigned x: Double, @assigned y: Double) {}
>   public init(self.x: Double, self.y: Double) {}
>   // something else
> 

I’ll ask you the same question I asked David about this approach: if the parameter must be explicitly related to a property for assignment, why should we repeat the type information (and default value information if it is a var)?  Doesn’t it seem reasonable to omit the type?

> For comparison with other languages, the "memberwise initializer" proposal is closest to C's brace-initialization, but C structs aren't resilient to change in the way that classes are, and they won't break if you reorder the members, while this will. The "annotation on parameters" idea is precedented in CoffeeScript, but I don't know of any other languages that do it.
> 
> This proposal is very practical and covers many common use cases, but I just don't see it as naturally fitting into the language.
> 
> Best,
> Jordan
> 
> 
>> On Jan 6, 2016, at 14:47, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md>
>> 
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>> 	https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> 	* What is your evaluation of the proposal?
>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
>> 	* Does this proposal fit well with the feel and direction of Swift?
>> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris
>> Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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