[swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[Chris Lattner]

> On Apr 26, 2016, at 3:30 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Apr 26, 2016, at 1:33 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Apr 26, 2016, at 5:56 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> 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