+1, provided it doesn't make life difficult for the compiler. Sent from my iPhone
> On May 13, 2016, at 11:13, 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 }". > > -Rob > _______________________________________________ > 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
