> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution
> <swift-evolution@swift.org> wrote:
>> On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On May 20, 2016, at 10:25, John McCall <rjmcc...@apple.com
>>> <mailto:rjmcc...@apple.com>> wrote:
>>>
>>>> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
