[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Matthew Johnson matthew at anandabits.com
Wed Jan 6 19:23:52 CST 2016 

On Jan 6, 2016, at 7:21 PM, Matthew Johnson <matthew at anandabits.com> wrote:


> On Jan 6, 2016, at 6:39 PM, Alex Johnson <ajohnson at quickleft.com <mailto:ajohnson at quickleft.com>> 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 <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
>> 
>> On Jan 6, 2016, at 5:26 PM, Alex Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>  <>https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/8c06d36e/attachment.html>

More information about the swift-evolution mailing list