<div dir="ltr">+1. I've built APIs before where I wanted a method to take a closure that had multiple arguments, but where I would also like the client to be able to ignore the extra arguments if they didn't need that level of detail, and it would be nice to not require them to acknowledge those extra parameters with `_`. Right now, I have to provide multiple overloads for that:<br><div><br></div><div>func foo(body: (Arg1, Arg2, Arg3) -> Result) { ... }</div><div><div style="font-family:'helvetica neue',helvetica,arial,sans-serif">func foo(body: (Arg1, Arg2) -> Result) { ... }</div><div style="font-family:'helvetica neue',helvetica,arial,sans-serif">func foo(body: (Arg1) -> Result) { ... }</div><br class="inbox-inbox-Apple-interchange-newline"></div><div>Allowing closure to just work with fewer arguments would make this bloat go away.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 13, 2016 at 9:25 AM Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><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>
<br>
> On May 13, 2016, at 11:16 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">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" target="_blank">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>
+1. Having to explicitly discard unnecessary arguments bugs me every time I have to do it.<br>
<br>
><br>
> -Joe<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">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" target="_blank">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>
</blockquote></div>