> On Jan 6, 2016, at 5:23 PM, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Jan 6, 2016, at 6:04 PM, Dave Abrahams via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution
>>> <[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
>>>
>>>
>>> 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.
>
> It isn’t clear to me how generic variadics might obsolete the functionality
> of this proposal. Can you elaborate on that?
Not sure if this is exactly what Dave has in mind, but an idea that comes to
mind: we could say that structs and classes have a magic "members" tuple and
typealias:
struct Foo {
var x, y: Int
// Implicit members
typealias Members = (x: Int, y: Int)
var members: Members {
get { return (x: x, y: y) }
set { (x, y) = newValue }
}
}
With plausible future features for forwarding tuples as arguments, then the
memberwise initializer could be implemented like this:
// Say that a parameter declared 'x...' receives a tuple of
arguments labeled according to its type,
// like '**x' in Python
init(members...: Members) {
self.members = members
}
And I think all your other use cases could be covered as well.
-Joe_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
