[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