> This example is introducing two things: convenience inits, but also parameter
> arguments. For the sake of the proposal, I’d suggest splitting the parameter
> arguments out to its own discussion. It isn’t clear to me whether the
> memberwise initializers should come before explicit arguments or after, and
> it isn’t clear if we should require the developer to put something in the
> code to indicate that they exist. For example, I could imagine a syntax like
> this:
>
> memberwise init(…) {}
> memberwise init(describable: CustomStringConvertible, ...) {
>
> Where the … serves as a reminder that the init takes a bunch of synthesized
> arguments as well.
Perhaps we should drop the `memberwise` keyword and say:
init(members) {}
init(describable: CustomStringConvertible, members) {
Or even:
init(vars) {}
init(describable: CustomStringConvertible, vars) {
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
