On Jan 6, 2016, at 7:21 PM, Matthew Johnson <[email protected]> wrote:
> On Jan 6, 2016, at 6:39 PM, Alex Johnson <[email protected] > <mailto:[email protected]>> wrote: > > Hi Matthew, > > Thanks for the explanation. > > Before getting into a deeper discussion, I'd like to try to enumerate the > reasons for adding the placeholder as I understand them: > Does that seem accurate? >> Add clarity by visually distinguishing memberwise initializers from normal >> initializers. >> Introduce a "synthesized parameters placeholder" syntax that might be useful >> in other places. >> Allow some control over where the synthesized memberwise parameters end up >> in the initializer signature. This is mostly correct (in terms of my motivation - Chris may have additional reasons). The point about clarity in regards to the `…` is about making it clear when looking at the signature that synthesized parameters are included in addition to those that are manually specified. This the most important point. The `memberwise` declaration modifier on the initializer itself is what distinguishes memberwise initializers from other initializers. Matthew > > ~ Alex > > > On Wed, Jan 6, 2016 at 3:48 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> >> On Jan 6, 2016, at 5:26 PM, Alex Johnson via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]> >> <>https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
