> On May 20, 2016, at 10:46 AM, Erica Sadun <[email protected]> wrote:
>> On May 20, 2016, at 11:42 AM, John McCall <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>> On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>> On May 20, 2016, at 10:25, John McCall <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution
>>>>>> <[email protected] <mailto:[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.
>>>>
>>>> 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.
Right, this was directed to other people.
> Thus, it sounds like I should kick back and cross this off my "take action"
> list. Right?
Sounds good to me!
John.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
