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

John McCall rjmccall at apple.com
Thu May 19 13:05:21 CDT 2016


> On May 14, 2016, at 10:16 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>> 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 }
> 
> I agree, but I consider this to be an obvious bug in the compiler.  I don’t think it requires a proposal.
> 
> Unfortunately it is non-trivial to fix…

Yeah, this is just a bug which several people have made various efforts over the last three years to fix.  It's not easy.

John.


More information about the swift-evolution mailing list