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

[Matthew Johnson]

Thanks for responding Brent.  I agree with all of your comments.

> On Dec 22, 2015, at 12:39 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> Also, I don’t think it generates good API signatures. Take this example:
>> 
>> struct S {
>> 	let s: String
>> 	let i: Int
>> 
>> 	// user declares:
>> 	memberwise init() {}
>> 	// compiler synthesizes:
>> 	init(s: String, i: Int) {
>> 		self.s = s
>> 		self.i = i
>> 	}
>> }
>> 
>> That is not a very descriptive API.
> 
> Well, yeah. This is a toy example. Do you often write APIs with properties like `s` and `i`? Or, for that matter, structs named `S`?
> 
>> It’s also not necessarily the case that your internal names are what you want exposed.
> 
> The proposal already states that a memberwise initializer only includes parameters for properties that are at least as visible as the initializer itself. So if you can see the `s` and `i` parameters, you can also see the `s` and `i` properties. It's not going to expose anything that isn't already visible.
> 
>> I would actually prefer the rule to simply be this: when an init() is modified by memberwise, the labelled parameters will be set. This lookup will try both the argument name and the parameter name, in that order, for reasons that become more clear with convenience inits described later.
>> 
>> So you would have this:
>> 
>> memberwise init(name s: String, value i: Int) {
>>    // autogenerated: self.s = s; self.i = i
>> }
> 
> That seems awfully inconvenient for a convenience feature.
> 
> -- 
> Brent Royal-Gordon
> Architechies
>