Yes, I expect that with the implemented proposal SE-0110 your code will not
compile because `moveTo` has type `(Int, Int)->Void` and not required
`((Int, Int))->Void`. You'll need to change the moveTo to accept tuple
argument or use some function/operator to transform argument list
parametrized function to function with tuple argument.
For example (this compiles now and IMO should after SE-0110 implemented, if
accepted):
//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(unwrapped)
}
return nil
}
//some defined functions
func defaultDestination() -> (x: Int, y: Int) {return (1,1) }
func loadedDestination() -> (x: Int, y: Int)? {return nil }
// ---- Variant 1 ----
func moveTo1(point: (x: Int, y: Int)) {print("move1 to: ", point.x, point.y)}
// ---- Variant 2 ----
func moveTo2(x: Int, y: Int) {print("move2 to: ", x, y)}
func tupleize<T,U,V>(_ f: (T,U)->V ) -> ( ((T, U))->V ) {
return { tu in return f(tu.0, tu.1) }
}
//actual code
defaultDestination() => moveTo1
(loadedDestination() ?=> moveTo1) ?? print("load1 failed")
defaultDestination() => tupleize(moveTo2)
(loadedDestination() ?=> tupleize(moveTo2)) ?? print("load2 failed")
If we'll have such `tupleize` as built-in operator, then things will be
even better. Don't see any problem here just like you, for example, don't
expect function of (Int, (Int, String))->() will be accepted where (Int,
Int, String)->() is required an so on. List of function arguments is not
tuple at these days and so IMO only explicit conversion can exist to accept
second when first is required and vice-versa. But I'm storng +1 to have
such handy convertion operator.
On 01.07.2016 17:16, James Froggatt via swift-evolution wrote:
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
