> On Dec 21, 2015, at 10:39 PM, Brent Royal-Gordon <br...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
