> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution
> <[email protected]> wrote:
>
> Currently if a closure takes a value, it requires "_ in" to note that the
> value is ignored. This makes sense in many cases, but creates a bit of a mess
> in the case of an empty, void-returning closure:
>
> doThing(withCompletion: { _ in })
>
> I'd like to suggest that the compiler promote the empty closure literal {} to
> any void-returning closure type so that this could be written:
>
> doThing(withCompletion: {})
>
> This encourages the use of empty closures over optional closures, which I
> think is open for debate. In general I try to avoid optionals when they can
> be precisely replaced with a non-optional value. Furthermore, most Cocoa
> completion handlers are not optional.
>
> The alternative is to not do this, but encourage that any closure that could
> reasonably be empty should in fact be optional. I would then want Cocoa
> functions with void-returning closures to be imported as optionals to avoid
> "{ _ in }".
+1. In general, I think we should allow implicit arguments, without requiring
the closure to use all the implicit $n variables like we do today. These should
all be valid:
let _: () -> () = {}
let _: (Int) -> () = {}
let _: (Int, Int) -> Int = { 5 }
let _: (Int, Int) -> Int = { $0 }
let _: (Int, Int) -> Int = { $1 }
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
