> 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
