<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>+1, provided it doesn't make life difficult for the compiler.<br><br>Sent from my iPhone</div><div><br>On May 13, 2016, at 11:13, Rob Napier via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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:<div><br></div><div><font face="monospace, monospace">doThing(withCompletion: { _ in })</font></div><div><br></div><div>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:</div><div><br></div><div><div><font face="monospace, monospace">doThing(withCompletion: {})</font></div></div><div><font face="monospace, monospace"><br></font></div><div><span style="font-family:arial,helvetica,sans-serif">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.</span><br></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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 }".</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">-Rob</font></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>