Thanks for responding Brent. I agree with all of your comments. > On Dec 22, 2015, at 12:39 AM, Brent Royal-Gordon <[email protected]> > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
