[swift-evolution] [Proposal Draft] parameter forwarding

Chris Lattner clattner at apple.com
Tue Jan 12 00:33:32 CST 2016

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.

> 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. 

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.


More information about the swift-evolution mailing list