[swift-evolution] [Proposal Draft] parameter forwarding

[Matthew Johnson]

> On Jan 12, 2016, at 12:28 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Jan 12, 2016, at 7:05 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>>> 
>>> Related but different: forwarding of varargs is also a common special case.  People have wanted to do this for a long time, we just haven’t had cycles to implement it:
>>> 
>>> func f(a : Int, b : Float…) {
>>> g(a, …b)  // unpack the vars array into a list of parameters. 
>>> }
>> 
>> I could see that being useful.  Would it have to unpack into a varargs argument since the length is not statically knowable?
> 
> Yes, exactly.
> 
>>> If we did that, I could see generalizing it to an arbitrary tuple:
>>> 
>>> g(x, y, …sometuple, z) 
>>> 
>>> where sometuple’s members got passed as arguments.
>> 
>> That covers cases where the subset of arguments is sequential.  I think that would address the vast majority of cases at the site of the forwarding call.
>> 
>> What do you think of the idea Brent and I discussed about being able to reference a function's parameters in a signature?
> 
> I haven’t had a chance to keep up with the thread.  I’m still trying to figure out what to do with memberwise, and you guys are building incredibly intricate castles in the clouds :-)

Well that certainly isn’t the intent.  I’m sorry if it seems that way.

Normally I wouldn’t have shared a bunch of early proposal drafts all at once.  I did that because I thought it would be helpful to put together new ideas / approaches that I came up with during the review.  In particular, building on more general underlying features.

> 
> My one meta-comment is that you should focus on making extensions to swift *small*, *obvious*, *orthogonal* and for them to pay for themselves.  In the partial function proposal for example (which I also haven’t had time to read), I saw a comment go by about parameter forwarding.  I’d strongly recommend *not* baking any notion of parameter forwarding into that proposal.  Doing so makes it more complex and more likely to be rejected.

I included initializer forwarding in there for a couple reasons.  

The primary reason was to show how partial initializers + initializer forwarding + implicit memberwise partial initializers can replace the explicit memberwise initializers with more general initialization features, moving memberwise from special syntax to an identifier for an implicit partial initializer.  This seems like a win and it is hard to demonstrate if it is spread out across several proposals.

Here’s an example in case you didn’t look at that part of the proposal:

// flexibile memberwise initialization proposal:
memberwise init(...) {
  // init all private props
}  
// corresponding syntax using implicit partial init and forwarding:
init(…memberwise) { // memberwise is an implicit partial initializer with the `memberwise` identifier
  // init all private props
}
// expands to a call to the partial initializer
init(arg1: Type1, arg2, Type2, arg3: Type3) {
  memberwise.init(arg1, arg2, arg3)
  // init all private props
}

The secondary reason is that I think partial initializers are far more useful with initializer forwarding than without it.  In many cases the bodies of partial initializers may be relatively simple.  If you have to manually declare forwarding parameters and write the forwarding call simple partial initializers won’t gain you nearly as much.  Even when they are non-trivial, much of the time their parameters will simply be forwarded.  IMO it is a much better feature with support for initializer forwarding.

That said, I will remove that section if it makes the proposal more likely to be rejected.  

In any case, I do think partial initializers + initializer forwarding is the right long-term approach for explicit memberwise initializers as they are more general features and allow for full control over the partial memberwise initializer.


> 
> If you’re interested in building a series of proposals that all work together, then that is great, but it depends on them initial proposals being *accepted* and us getting at least some experience with them first.

Sure.  Like I said, I shared a bunch of ideas at once because they are relevant to the memberwise init review and came out of that discussion.  If that was a mistake I won’t do it again.

Matthew