> On May 14, 2016, at 10:16 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution > <[email protected]> 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
