[swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

[Vladimir.S]

On 02.07.2016 4:20, Daniel Duan via swift-evolution wrote:
>> Vladimir.S via swift-evolution <swift-evolution at ...> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>