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

[David Owens II]

> On Dec 21, 2015, at 10:39 PM, 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`?

I often write APIs where the internal member’s name is not what I want to use as the label for the public API. 


>> 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.

This isn’t about access modifiers, it’s about the name chosen for internal variables vs. names chosen for API contracts.

-David