> On 3 Jul 2016, at 13:02, Vladimir.S via swift-evolution > <[email protected]> wrote: > > 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.
I think the issue is that it's unexpected; I would expect () -> Void to mean no arguments at all, rather than one argument that is Void, as I can't really envision any cases where I'd need the latter. I think it's reasonable that for those who can, that they use (()) -> Void to clarify that this is the case, which I think fits well with Swift's general philosophy of avoiding mistakes, even if this is probably a minor one, it removes an area of confusion or inconsistency. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
