> 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