[swift-evolution] Removing "_ in" from empty closures

[Nicholas Maccharoli]

+1


All the best,

Nicholas

Linked in:
http://lnkd.in/328U22


On Mon, May 16, 2016 at 7:27 AM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Fri May 13 2016, Joe Groff <swift-evolution at swift.org> wrote:
>
> >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution <
> swift-evolution at 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
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160517/9bc74f85/attachment.html>