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

Alex Johnson ajohnson at quickleft.com
Thu Jan 7 13:23:09 CST 2016 

Meanwhile, back on the topic of the "..." placeholder.

For me, it boils down to:

   1. The addition of the "memberwise" keyword and associated behavior
   would stand on it's own, without the inclusion of the "..." placeholder
   syntax. (IMO)
   2. Omitting the "..." placeholder syntax *now* wouldn't prevent it from
   being added *later*.

If you agree with those statements, then the principle of "smallest,
incremental change <https://swift.org/contributing/#incremental-development>"
[swift.org] seems to imply that the placeholder should be removed from this
proposal.

That's my opinion. Does the rest of the community feel that the "..."
placeholder is a *necessary* part of this proposal?

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

>
> 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> 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>
> 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
>>
>
>


-- 

*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>*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/087244d0/attachment.html>

More information about the swift-evolution mailing list