[swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types
T.J. Usiyan
griotspeak at gmail.com
Fri Jul 1 18:37:11 CDT 2016
+1 if SE-0111 is accepted. 0 otherwise.
On Fri, Jul 1, 2016 at 7:34 PM, Vladimir.S via swift-evolution <
swift-evolution at swift.org> wrote:
> 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
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160701/a28dac44/attachment.html>
More information about the swift-evolution
mailing list