[swift-evolution] Removing "_ in" from empty closures

[Dave Abrahams]

on Fri May 13 2016, Joe Groff <swift-evolution at swift.org> wrote:

>> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution <swift-evolution at swift.org> 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 }

+1

-- 
-Dave