[swift-evolution] [Proposal Draft] parameter forwarding

[Matthew Johnson]

Sent from my iPad

>> On Jan 12, 2016, at 12:33 AM, Chris Lattner <clattner at apple.com> wrote:
>> 
>>> On Jan 11, 2016, at 6:00 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>>> 
>>> 
>>> Another major problem with this approach is that it only works if “foo” is unambiguous.
>> 
>> I addressed the fact that the call to foo must be unambiguous further down in the proposal.  Did I miss something important?  (Not that it matters if this approach is a dead end)
> 
> No, you have it covered.  I know you’re interested in initializer forwarding in particular, and overloaded initializers are very common, that’s why I raised it as a potential issue.

Makes sense.  This is one reason I introduced identifiers in the partial initializers proposal, but certainly not the only reason.

It probably seems like I'm obsessed with initialization by now!  I'm really not.  Initialization boilerplate just happens to be the first thing I decided to work on after the open source release.  I like to see something through when I start on it. 

> 
>> Do you have any ideas for a better direction that could handle forwarding of default parameter values and / or a subset of parameters?  Or is tuple packing and unpacking the best we can hope for?
> 
> There is no structural problems with mechanisms that take parameters and forward to other calls, e.g.:
> 
> 
> func f(a : Int, b : Float, c : String) {
>   bar(@@@ARGS@@@)   // obviously horrible to get the point across :-)
> }
> 
> 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? Valued it also work for any array of the correct type?

> 
> 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?  This would allow for a relatively concise way to declare a tuple to forward, and hopefully also include the default arguments.

If we could accomplish both of these it would go pretty far.  Would it be worth rewriting the proposal in this manner?

Matthew

> 
> -Chris