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

[Leonardo Pessoa]

+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 at swift.org> wrote:

>
>
> Sent from my iPad
>
> > On May 13, 2016, at 11:16 AM, Joe Groff via swift-evolution <
> 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.  Having to explicitly discard unnecessary arguments bugs me every time
> I have to do it.
>
> >
> > -Joe
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20160513/fc25f9ff/attachment.html>