Sent from my iPad
> On May 13, 2016, at 11:16 AM, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
