[swift-evolution] Variadics through tuples

[James Froggatt]

Currently, the following code is allowed:

//function application operator
infix operator => {}
func =><In, Out>(a: In, b: In -> Out) -> Out {
    return try b(a)
}

infix operator ?=> {}
func ?=><In, Out>(a: In?, b: In -> Out?) -> Out? {
    if let unwrapped = a {
        return try b(a)
    }
    return nil
}

//some defined functions

func defaultDestination() -> (x: Int, y: Int)
func loadedDestination() -> (x: Int, y: Int)?
func moveTo(x: Int, y: Int)

//actual code

defaultDestination() => moveTo
loadedDestination() ?=> moveTo ?? print("load failed")

//code without functional chaining

let point = defaultDestination()
moveTo(x: point.x, y: point.y)

if let loaded = loadedDestination() {
    moveTo(x: loaded.x, y: loaded.y)
} else {
    print("load failed")
}

I'm expecting this to stop working at some point in Swift 3's development, since it is related to tuple splat. I've heard talk of tuple splat returning in the future through an operator, with the stand-in syntax:

moveTo(*defaultDestination())

So, how would a functional chaining operator work under these conditions? It would require a second variadic splat operator:

defaultDestination() => *moveTo(x:y:)

The motivation for removing the standard form of tuple splat is that the calling syntax looks like an overload. But in this case, an explicit splat operator doesn't add any clarity, since the function being referred to can be unambiguous.



So, my question is whether this is worth removing full support for in the first place. This behaviour can be make to fit Swift 3's distinction of parameter lists and tuples, by applying specific rules to the existing behaviour to create a lightweight variadics system:

takesAClosure<T>(_: (T) -> ()) //closure explicitly takes a single parameter

takesAClosure<T>(_: T -> ()) //closure takes any number of parameters

takesAClosure<T>(_: T, _: T -> ()) //closure takes any number of parameters, but must have a parameter list which can be directly represented as a tuple



Either way, I'm hoping whatever syntax ends up chosen for variadics is nearly as simple to use as tuple splat has been, tuples are (literally) made for this purpose. I'll be disappointed to see this feature removed.