> On Dec 21, 2015, at 11:05 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >>> 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. > > But if you have a bad name in your memberwise initializer, that bad name is > *by definition* already part of your API contract as a property name. > > Stated another way: Either the name is already externally visible as a > property, and thus is not by any sensible definition an "internal" name, or > the memberwise initializer will not publish it.
I agree. With this design, memberwise initializers are an opt-in sugar feature. If you don’t want to publish the names of your properties, then write your initializer manually however you want it. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
