func add(a: Int, b: Int) -> Int {
return a + b
}
let lazyAdd: (Int, Int) -> (() -> Int) = { (a: Int, b: Int) in
return {
add(a: a, b: b)
}
}
let unappliedAddReference = lazyAdd(2, 3)
let result = unappliedAddReference() // 5
But you'll notice that the lazy method signature has to drop the named parameters, because function types cannot have argument labels. So we've lost the original method signature and it's also now quite difficult to read the lazyAdd method.
Swift used to have a defined curry syntax that would let you write:
func myCurriedFunc(_ y: Int)(_ x: Int)(_ z: Int) -> Int {
return y + x + z
}
let firstApplication = myCurriedFunc(2)
let secondApplication = firstApplication(3)
let result = secondApplication(3)
But this was removed in Swift 3? much to my chagrin. I used this quite a bit and I thought it was a fairly expressive feature. The issue I believe was that it caused a lot of complexity in the compiler. But I would love to see this type of feature again.
I suggest you read the proposal that removed it, and the alternatives considered. It brings up the idea of adding Scala like partial application syntax (which I love) and would be a massive +1 if this is put on the table.
Another reason might be that creating a standalone builder for a method with default parameters isn't possible, due to default argument not permitted in a tuple type. The following requires dropping the original default parameters to compile:
This is what I had in mind, @ebg. I don't know what argument labels have to do with it. You can see the argument labels in the closure that @DeFrenZ wrote. The call to the closure doesn't have labels because it doesn't have arguments. So this really does seem to be exactly what you wanted, just with a different syntax.