> On Apr 26, 2016, at 3:30 PM, Joe Groff <[email protected]> wrote:
>
>
>> On Apr 26, 2016, at 1:33 PM, Chris Lattner via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>> On Apr 26, 2016, at 5:56 AM, Vladimir.S via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> On 26.04.2016 9:38, Goffredo Marocchi via swift-evolution wrote:
>>>>
>>>> Agreed, the exception for the parameter list in a closure declaration
>>>> should be gone too potentially, I do not see a very convincing case why we
>>>> should keep it. Does it solve some particular problem now in its current
>>>> form?
>>>
>>> Probably support. If we want to be clear about if parameter list is a tuple
>>> or it is a list of values i.e. (Int,Int) -> Void vs ((Int,Int)) -> Void ,
>>> IMO we should be also clear about parameter list in a closure declaration..
>>>
>>> But it seems right now it is not just about syntax:
>>
>> Yes, closure expressions have other problems. For example, if a closure
>> expression contextually takes two parameters, it is invalid to use $0
>> without also using $1. :-(
>
> IIRC that restriction arose out of tuple splatting ambiguities, so we should
> be able to fix now that we've done away with splatting (as another proposal,
> of course).
The last time I looked at this, it was due to implementation limitations, not
due to concern with tuple splat. For example, we reject:
func f(a : (Int, Int, Int) -> Int) {}
f { $1+$0 }
Even though tuple splat can’t be at work here. This should clearly be fixed,
I’m just pointing out that it is orthogonal to the specific 0066 syntax
proposal.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
