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!_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
