[swift-evolution] [Proposal Draft] parameter forwarding

Chris Lattner clattner at apple.com
Tue Jan 12 12:28:20 CST 2016


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 :-)

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.

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.

-Chris


More information about the swift-evolution mailing list