On 02.07.2016 4:20, Daniel Duan via swift-evolution wrote:
Vladimir.S via swift-evolution <swift-evolution@...> writes:
Following your conclusion, should this be legal as well?
let f: () -> Void = { x in print(x) } // f() prints "()"
let f: (Int) -> Void = { x in print(x) } // f(5) prints "5"
In other words, "0 argument" is an impossible scenario?
I don't see problems here. ()->Void means (Void)->Void, there *is* one
parameter of Void type, which we can omitted as it is empty tuple. So, if
you want you can write f(()) or or let z = (); f(z); or just f(), so in
closure definition you can have one argument or can have 0 defined
arguments if the only argument is of type Void.
It is not the same as be able to accept non-empty tuple when a list of
parameters are expected or vice-versa.
I don't think we should move away(if it is possible at all) from
representing zero-argument by empty tuple(Void). This looks like good and
useful thing in Swift, especially in functional programming and when
working with generics (we can pass parameter(of type void) even when call
function with 0 defined arguments).
I actually wonder what should be a type of such function:
func f1() {}
print(f1.dynamicType)
Now it is `(()) -> ()`. Should it be `() -> ()`? Seems like no - it
actually take 1 argument(empty tuple, Void) and returns empty tuple. So the
`() -> ()` *declaration* just still be just an alias for real type `(()) ->
()`. IMO.
_______________________________________________
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
