> On Jan 6, 2016, at 6:39 PM, Félix Cloutier via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Meta: most reviews have the review dates in the Status field of their
> document, this one doesn't. I was a little confused at first.
>
> For the proposal itself:
>
> # What is your evaluation of the proposal?
>
> +1
>
> # Is the problem being addressed significant enough to warrant a change to
> Swift?
>
> Yes, I write a lot of code just to initialize code. This will probably make
> some of that code clearer.
>
> # Does this proposal fit well with the feel and direction of Swift?
>
> Probably?
>
> # If you have you used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
> I frequently write C++ and Python and neither of them have it. This is
> especially annoying for short programs.
>
> # C# has an initializer syntax that allows you to assign properties at
> creation time, and it is handy:
>
>> Foo foo = new Foo() {
>> Bar = "bar",
>> Baz = 1,
>> };
>
> However, this pattern wouldn't be of much help in Swift, where most types
> don't have a reasonable default value.
>
> # How much effort did you put into your review? A glance, a quick reading, or
> an in-depth study?
>
> I followed the first week and a half of the proposal.
>
> With all this said, I am confused with the way the proposal is written. The
> Proposed Solution section talks about opt-in memberwise initialization with
> the memberwise modifier on properties, but it is listed as a future direction
> and the Detailed Design makes no mention of it. I would like to be clear that
> my current appreciation of the proposal only extends to the Detailed Design,
> and not necessarily to the future directions.
Felix, I apologize if this was confusing. The decision of the “automatic” vs
“opt-in” model for property eligibility is one that I feel is very important.
That is why I mentioned the tradeoff in the Proposed Solution section.
The opt-in model is not part of the current proposal. The Detailed Design
describes exactly how the current proposal will work. I appreciate your
support of that!
The future enhancements are included to give an idea of some directions in
which memberwise initialization could evolve. I feel strongly about two
aspects of these enhancements:
1. We need a way to specify a default value for memberwise parameters for `let`
properties.
2. It would be really nice to have a little bit more control over which
properties participate in memberwise initialization when the “automatic” rules
don’t quite do the right thing for a particular use case.
Matthew
>
> Félix
>
>> Le 6 janv. 2016 à 19:04:41, Dave Abrahams via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>
>>>
>>> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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-
>>>
>>> <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?
>>
>> It’s okay.
>>
>>> * Is the problem being addressed significant enough to warrant a change
>>> to Swift?
>>
>> I’m lukewarm about that. I have never found writing out the initializers I
>> want to be a significant burden, and I find my code is better when they’re
>> explicit. Every new feature increases the language's complexity and surface
>> area, and I fear this one is not going to pay its way.
>>
>>> * Does this proposal fit well with the feel and direction of Swift?
>>
>> Yes, but I worry that it may be too early to add it. Other features in this
>> space, like truly generic variadics, may well obsolete anything we do today.
>> I’m not sure we should be designing convenience features that are likely to
>> overlap with more general features coming down the road unless the
>> inconvenience is very painful… which I personally don’t find it to be.
>>
>>> * If you have you used other languages or libraries with a similar
>>> feature, how do you feel that this proposal compares to those?
>>
>> The proposal is more elegant than how you’d do this in Python, but on the
>> other hand the mechanisms you’d use in Python are not single-purpose
>> language features directed at memberwise initialization; they definitely pay
>> their way because they can be used for much more.
>>
>>> * How much effort did you put into your review? A glance, a quick
>>> reading, or an in-depth study?
>>
>> A glance, admittedly.
>>
>>> 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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> -Dave
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
