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

[Joe Groff]

> On Jan 7, 2016, at 8:28 AM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> The latter I'm afraid. 

I was just discussing this design space with Chris Willmore, who's been working on revamping how our function type model works. If we move to a multiple-argument model for functions rather than the current every-function-takes-a-tuple-argument model, then we will likely need at least limited support for packing and unpacking tuples from and to arguments in order to avoid regressing at argument forwarding use cases. However, even that limited packing/unpacking functionality might be enough to seriously consider a more general magic "members" property as an alternative.

-Joe

> Sent from my moss-covered three-handled family gradunza
> 
> On Jan 6, 2016, at 7:12 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Jan 6, 2016, at 8:46 PM, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>> 
>>> 
>>> 
>>> Sent from my moss-covered three-handled family gradunza
>>> 
>>> On Jan 6, 2016, at 5:47 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>> 
>>>> 
>>>>> On Jan 6, 2016, at 5:23 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 6, 2016, at 6:04 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Jan 6, 2016, at 2:47 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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 <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 <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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/75ba9dad/attachment.html>