+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 < [email protected]> wrote: > > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
