> On Dec 21, 2015, at 8:12 PM, Brent Royal-Gordon <br...@architechies.com>
> wrote:
>
>> 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
>
That’s an interesting idea as well. A placeholder for the synthesized
arguments is definitely an improvement to the proposal regardless of what
syntax we end up with.
I’m open to plenty of bikeshedding on the details of syntax. :)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
