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

[Erica Sadun]

> On May 20, 2016, at 11:42 AM, John McCall <rjmccall at apple.com> wrote:
> 
>> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On May 20, 2016, at 10:25, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>>> 
>>>>> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>>> 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 }
>>>>>> 
>>>>>> I agree, but I consider this to be an obvious bug in the compiler.  I don’t think it requires a proposal.
>>>>> 
>>>>> Sorry to find this thread late. I don’t think this is just a bug; it’s also a way to check that a parameter isn’t getting forgotten. For a single-expression closure that’s probably overkill, but maybe we’d keep the restriction for multi-statement closures?
>>>> 
>>>> The bug we're talking about is that closures have to have a reference to $n when there are n+1 parameters.
>>> 
>>> Oh, I completely forgot that it’s only $n you have to reference, not $n-1 or anything else. So I guess it’s not quite serving the purpose I thought it was.
>>> 
>>> Jordan
>> 
>> Who knew?  http://i.imgur.com/8ytNkn0.jpg <http://i.imgur.com/8ytNkn0.jpg> !
>> 
>> So anyway, how hard a problem is this to fix? And do you want me to submit the proposal as a PR or not?
> 
> Not requiring you to refer to the last argument is a bug fix, and not requiring "_ in" will fall out from that fix.  I think that means there's nothing left to propose.  If anyone feels strongly that you should have to do *something* to ignore arguments, at least if you're ignoring all of them, that should be its own proposal.
> 
> John.

History to date: 

1. draft proposal:  https://gist.github.com/erica/3731e24fc252c8e66850e0e02f491281 <https://gist.github.com/erica/3731e24fc252c8e66850e0e02f491281>

2. bug report: https://bugs.swift.org/browse/SR-1528 <https://bugs.swift.org/browse/SR-1528> (although it seems the bug is wrongly named, and should be "requires reference to ultimate anonymous argument, not all arguments)

I do not feel strongly that you should have to do *anything* to ignore arguments. It should be magical.

Thus, it sounds like I should kick back and cross this off my "take action" list. Right?

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/edb17df2/attachment.html>