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

[David Owens II]

You forgot that parentheses are required for labeled closures with type information:

x.sorted { (x: Int, y: Int) in x > y }

You'd have to handle that case as well.


x.sorted { x: Int, y: Int in x > y }

I think the above leads to potentially ambiguous parsing constructs. 

Sent from my iPhone

> On Apr 27, 2016, at 1:18 PM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution <swift-evolution at swift.org>:
>> 
>> > But keep away from closure expressions, please! There is nothing ambiguous
>> > there.
>> 
>> Really?
> 
> Ok, you got me there :-)
> I have to clarify: no ambiguity if parentheses would be prohibited around parameter lists in closure expressions like I suggested. 
> Furthermore the current implementation seems to do some auto-(un)splatting which should go away.
> 
>> 
>> func z1(block: (Int,Int) -> Void) {
>>    block(1,2)
>> }
>> 
>> z1 { x, y in print(x,y)} //
> 
> (Int, Int) is a parameter list, so this is ok
> 
>> z1 { x in print(x.0, x.1)} // ???
> 
> This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
> Seems to be tuple unsplatting at work here.
> 
>> z1 { (x, y) in print(x, y)} //
> 
> This should not work for the given definition of z1 as (x, y) is a tuple.
> 
>> func z2(block: ((Int,Int)) -> Void) {
>>    block((1,2))
>> }
>> 
>> z2 { x, y in print(x,y)} // ???
> 
> This should not work IMO (tuple splatting at work here)
> 
>> z2 { x in print(x.0, x.1)}
> 
> Fine, as x is a tuple.
> 
>> z2 { (x, y) in print(x, y)} // ???
> 
> Fine, as (x, y) is a tuple. This raises another issue, though: this is using pattern matching without having to write `let` or `case let`. That’s probably a good thing and I’d rather like to get rid of `let` for bindings in pattern matching in other places.
> 
>> //z2 { ((x, y)) in print(x, y)}  // compilation error
> 
> This should not work IMO as parentheses should not be allowed around argument lists in closure expressions.
> 
>> 
>> // this will compile, but
>> runtime error
>> let ft : (Int,Int) -> Void = { x in print(x)} // hm..
>> ft(1, 2)
> 
> There is no runtime error in my playground.
> The result printed is (1, 2)
> 
> This should not work IMO as the type is (Int, Int) -> Void where (Int, Int) is a parameter list and not a tuple.
> You would have to write
> let ft : (Int,Int) -> Void = { x, y in print(x, y) } // 1 2
> or
> let ft : ((Int,Int)) -> Void = { x in print(x) } // (1, 2)
> 
> 
> To rehash:
> 
> Rules for function type definitions:
> - parentheses are required around argument lists of more than one argument, i.e. (Int, Int) -> Void (same as in SE-0066)
> - parentheses are required around argument lists with a single tuple argument, i.e. ((Int, Int)) -> Void (same as in SE-0066)
> - parentheses are prohibited around single non-tuple arguments, i.e. Int -> Void (different from SE-0066)
> 
> Rule for argument lists in closure expressions:
> - parentheses are prohibited around the argument list (as it is clearly enclosed by `{ … in`, therefore parentheses can only be used for tuples (different from current state)
> 
> This would result in nice unambiguous code without unnecessary parentheses.
> 
> -Thorsten
> 
> 
>> 
>>> On 27.04.2016 11:53, Thorsten Seitz via swift-evolution wrote:
>>> I am strictly against requiring parentheses in closure expressions.
>>> Parentheses are visual clutter if not really needed and for a closure
>>> expression there is no need for parentheses as the parameter list is
>>> already nicely bracketed by `{ ... in`.
>>> Actually I would argue that parentheses around parameter lists in closure
>>> expressions should be prohibited for that reason.
>>> 
>>> I'm not fond of requiring parentheses around single non-tuple parameters in
>>> type declarations either but I could probably grudgingly live with that change.
>>> But keep away from closure expressions, please! There is nothing ambiguous
>>> there.
>>> 
>>> -Thorsten
>>> 
>>> 
>>> Am 27. April 2016 um 00:07 schrieb David Owens II via swift-evolution
>>> <swift-evolution at swift.org>:
>>> 
>>>> 
>>>>> On Apr 26, 2016, at 1:31 PM, Chris Lattner <clattner at apple.com
>>>>> <mailto:clattner at apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution
>>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> *What is your evaluation of the proposal?
>>>>>> *
>>>>>> I reluctantly agree with the proposal with the following caveat: I do
>>>>>> not agree with the rationale to support being able to choose to
>>>>>> omit the () for the parameter list of the closure declaration.
>>>>>> 
>>>>>> I see no cohesive argument that says that the parens should be required
>>>>>> in some cases but not in others when talking about parameter lists.
>>>>>> 
>>>>>> I believe the proposal should be amended that the following should be
>>>>>> the only allowable forms:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> To be clear, this proposal is not about changing closure expressions, it
>>>>> was just a FAQ, and the section at the end is simply my personal
>>>>> opinion.  Changing closure expression syntax would be a separate proposal.
>>>> 
>>>> My argument is changing the parameter list in one context but not the
>>>> other is only solving one of the potentially ambiguous use cases instead
>>>> of the general case. My opinion is they should be changed as the same
>>>> time if they are going to be changed at all.
>>>> 
>>>> -David
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/782ba6f7/attachment.html>