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

[Joe Groff]

> On Jan 7, 2016, at 10:22 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Jan 7, 2016, at 12:14 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>>> 
>>> On Jan 7, 2016, at 10:03 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>> 
>>> 
>>>> On Jan 7, 2016, at 11:39 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Jan 7, 2016, at 8:28 AM, Dave Abrahams <dabrahams at apple.com <mailto: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.
>>> 
>>> I don’t mind discussing an alternative using this approach.  If we’re going to do that I think it must be clear how it would cover various intended use cases in detail.  Specifically, how would we address:
>>> 
>>> 1. Default parameter values (at least for `var` properties)
>>> 2. `let` properties: it seems pretty magical indeed if the computed `var` property exposing the tuple could be used to initialize a `let` property.
>> 
>> Yeah, this member would need special initialization abilities, I agree.
> 
> It seems odd that this would be deemed acceptable.  Would the `members` member be usable outside of an initializer?  It seems like that wouldn’t be possible if there were a `let` property.  But it also seems weird if its availability was determined by whether you have a `let` property or not.
> 
>> 
>>> 3. Partial memberwise initialization exposing a subset of members following some kind of “automatic” or “opt-in” model for determining the subset.
>> 
>> Seems to me that could be done by factoring the interesting subsets into structs, e.g.:
>> 
>> class Foo {
>>   internal struct MemberwiseProperties {
>>     var x,y,z: Int
>>   }
>>   internal var state: MemberwiseProperties
>> 
>>   init(members...: MemberwiseProperties.Members) {
>>     state.members = members
>>   }
>> }
> 
> Sure you could do that, but it doesn’t seem like an acceptable alternative to me.  Now the members must be prefixed with an identifier everywhere they are used.  I don’t see why this is acceptable when requiring `self` is not.

That's a tradeoff, yes.

> Are there compelling reasons to go down this road rather than the current proposal?  What use cases does it address that the current proposal does not?

I find this approach interesting because it enables the easy implementation of at least most memberwise initializers, using more generally useful language features I think we are going to eventually want for argument forwarding and compile-time metaprogramming anyway. If we had already had these features, would you still have been compelled to write your proposal?

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