> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution
> <[email protected]> wrote:
>> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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.
John.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
