<div dir="ltr"><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif">+1 here and I don't think it will make life more difficult for the compiler as it already handles the examples <span style="font-size:12.8px;font-family:arial,sans-serif"><font color="#000000">Joe Groff provided. On the contrary, by removing the need for those "_ in" declarations and checks you make the life of the compiler easier.</font></span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">- Leonardo</div></div></div>
<br><div class="gmail_quote">On 13 May 2016 at 13:25, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Sent from my iPad<br>
<span class=""><br>
> On May 13, 2016, at 11:16 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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:<br>
>><br>
>> doThing(withCompletion: { _ in })<br>
>><br>
>> 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:<br>
>><br>
>> doThing(withCompletion: {})<br>
>><br>
>> 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>
>><br>
>> 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>
><br>
> +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>
><br>
> let _: () -> () = {}<br>
> let _: (Int) -> () = {}<br>
> let _: (Int, Int) -> Int = { 5 }<br>
> let _: (Int, Int) -> Int = { $0 }<br>
> let _: (Int, Int) -> Int = { $1 }<br>
<br>
</span>+1. Having to explicitly discard unnecessary arguments bugs me every time I have to do it.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> -Joe<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>