+1 here and I don't think it will make life more difficult for the compiler
as it already handles the examples Joe Groff provided. On the contrary, by
removing the need for those "_ in" declarations and checks you make the
life of the compiler easier.
- Leonardo
···
On 13 May 2016 at 13:25, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:
Sent from my iPad
> On May 13, 2016, at 11:16 AM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> 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:
>>
>> doThing(withCompletion: { _ in })
>>
>> 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:
>>
>> doThing(withCompletion: {})
>>
>> 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 }+1. Having to explicitly discard unnecessary arguments bugs me every time
I have to do it.>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution