Sent from my iPad
> On Jan 6, 2016, at 8:46 PM, Dave Abrahams <[email protected]> wrote:
>
>
>
> Sent from my moss-covered three-handled family gradunza
>
>> On Jan 6, 2016, at 5:47 PM, Joe Groff <[email protected]> wrote:
>>
>>
>>>> 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.
>
> That's exactly what I had in mind. Thanks, Joe!
Is there any chance of generic variadics along these lines being part of Swift
3? Or is this down the road further?_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
