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

[Vladimir.S]

On 02.07.2016 1:49, Daniel Duan via swift-evolution wrote:
> Chris Lattner via swift-evolution <swift-evolution at ...> writes:
>
> I think there's an edge case that needs consideration: when there's zero
> expected arguments and the '_' parameter is used:
>
> let f: () -> Void = { _ in }

As I understand current syntax and logic, there is *one* expected argument 
: Void. This is why we can call f(()). But we are allowed to omit that 
empty tuple parameter in syntax(on caller side and in function parameter 
list definition). So, IMO or this should be leaved as is, or we should move 
away from association between Void and "emptiness" of parameters(I don't 
understand if this is possible).

If we'll disallow this, will that be allowed:

func foo(_ x: Void) { print(x) }

foo()

and then question regarding

typealias MyFunc<T> = (T) -> Void

let myfunc1 : MyFunc<Int> = {i in print(i)}
let myfunc2 : MyFunc<String> = {s in print(s)}
let myfunc3 : MyFunc<Void> = {_ in print("nothing")}


Probably there is no problem with current behavior for empty tuple(Void) as 
soon as *one* parameter will be mapped to the same *one* argument(or zero 
arguments for this very special case).

Btw, don't we want to stop these games with recursive empty tuples:

foo(())
foo(((())))


>
> According to the proposal, this is syntactically incorrect ( 0 != 1 ). But it
> is legal now since '_' matches up with the empty tuple. Is there value to keep
> it legal?
>
> Either way, this may remain an implementation detail. But it might be
> beneficial to make it explicit in the proposal.
>
> - Daniel
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>