<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">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.<br class=""><br class="">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 }".<br class=""></blockquote><br class="">+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:<br class=""><br class="">let _: () -> () = {}<br class="">let _: (Int) -> () = {}<br class="">let _: (Int, Int) -> Int = { 5 }<br class="">let _: (Int, Int) -> Int = { $0 }<br class="">let _: (Int, Int) -> Int = { $1 }<br class=""></blockquote><br class="">I agree, but I consider this to be an obvious bug in the compiler. I don’t think it requires a proposal.<br class=""></div></div></blockquote></div><br class=""><div class="">Sorry to find this thread late. I <i class="">don’t</i> think this is just a bug; it’s also a way to check that a parameter isn’t getting forgotten. For a single-expression closure that’s probably overkill, but maybe we’d keep the restriction for multi-statement closures?</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></body></html>