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

Alex Johnson ajohnson at quickleft.com
Wed Jan 6 18:39:30 CST 2016 

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:

   1. Add clarity by visually distinguishing memberwise initializers from
   normal initializers.
   2. Introduce a "synthesized parameters placeholder" syntax that might be
   useful in other places.
   3. Allow some control over where the synthesized memberwise parameters
   end up in the initializer signature.

Does that seem accurate?

~ Alex


On Wed, Jan 6, 2016 at 3:48 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Jan 6, 2016, at 5:26 PM, Alex Johnson via swift-evolution <
> 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> 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
>>
>> 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
>>
>> 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
>>
>> Thank you,
>>
>> -Chris
>> Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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
> 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/3930321b/attachment.html>

More information about the swift-evolution mailing list