> On Jan 6, 2016, at 5:26 PM, Alex Johnson via swift-evolution > <[email protected]> wrote: > > (this is mostly a repost of a message I sent to the "[draft]" thread for this > proposal, with some light editing to better match terminology in the proposal) > > What is your evaluation of the proposal? > > I like this proposal. I think it will bring some much-needed ease-of-use. > > I have reservations about the "..." placeholder for the memberwise > initialization parameters, though. I know this was suggested by Chris > Lattner, so I'm inclined to defer to his judgement. But, here are my thoughts: > > First, it's very close to the varags syntax (e.g. "Int...") which can also > appear in initializer parameter lists. > > Second, and I think more important, I'm not sure that it's all that useful. > It's presence isn't necessary for triggering memberwise initialization > synthesis; that is already done by the "memberwise" keyword. > > The primary example given in the proposal is: > > memberwise init(anInt: Int, anotherInt: Int, ...) { > /* code using anInt and anotherInt */ > } > > That is, it's used to indicate where the synthesized parameters appear in the > parameter list if there are also custom (non-memberwise) parameters. > > My question is, could the memberwise initialization parameters always be > last? That would eliminate the need for the placeholder. > > I don't think I've seen a compelling case for embedding the "..." within a > list of custom arguments, like: > > memberwise init(anInt: Int, ..., anotherInt: Int) { > /* code using anInt and anotherInt */ > } > > It's been mentioned several times in the discussion of this proposal that > this behavior is purely optional. If it turns out that there are rare cases > where placing the memberwise params in the middle is useful, authors can use > manual initialization.
Hi Alex, thanks for your review. The initial draft of the proposal did exactly what you suggest - it did not include the placeholder and always placed the memberwise parameters last. Personally, I believe the placeholder adds clarity and really liked the idea when Chris suggested it. Aside from personal preference, I like that this proposal introduces a “synthesized parameter placeholder” syntax. Similar syntax will also be used in the parameter forwarding proposal mentioned in the future enhancements section of this proposal. I think the `…` works really well. That said, I don’t mind if people wish to bikeshed on it. If that discussion starts it is worth noting that one thing I like about the `…` is that it combines with an identifier cleanly. For example : `…memberwise`. Combining the placeholder with an identifier allows more than one placeholder to be used in the same parameter list. For example, if you are forwarding memberwise parameters exposed by a super init you might also have `…super`. That said, I don’t want the review thread to get distracted with discussions around general parameter forwarding so please just consider this as a preview of how this syntax might scale to future applications. For now, lets keep this thread focused on the review of the current proposal. :) Matthew > > > On Wed, Jan 6, 2016 at 2:47 PM, Chris Lattner via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Hello Swift community, > > The review of "Flexible Memberwise Initialization" begins now and runs > through January 10th. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md> > > Reviews are an important part of the Swift evolution process. All reviews > should be sent to the swift-evolution mailing list at > > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > or, if you would like to keep your feedback private, directly to the review > manager. > > What goes into a review? > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > * What is your evaluation of the proposal? > * Is the problem being addressed significant enough to warrant a > change to Swift? > * Does this proposal fit well with the feel and direction of Swift? > * If you have you used other languages or libraries with a similar > feature, how do you feel that this proposal compares to those? > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > <https://github.com/apple/swift-evolution/blob/master/process.md> > > Thank you, > > -Chris > Review Manager > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > -- > > Alex Johnson | Engineering Lead > > Quick Left, Inc. <https://quickleft.com/> > Boulder | Denver | Portland | San Francisco > 1 (844) QL-NERDS > @nonsensery > > <https://github.com/quickleft> <https://www.facebook.com/quickleft> > <https://twitter.com/quickleft> <https://instagram.com/quick_left/> > <https://www.flickr.com/photos/quickleft> <https://vimeo.com/quickleft> > > <> > What's it like to work with us? TrainingPeaks, iTriage, and Ping Identity > share their stories in this short video A Client's View > <https://vimeo.com/92286352>. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
