> Am 28.04.2016 um 00:38 schrieb David Owens II <[email protected]>:
>
> 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.
That’s a single tuple argument.
> x.sorted { x: Int, y: Int in x > y }
And that’s an argument list with two arguments.
> I think the above leads to potentially ambiguous parsing constructs.
Why? The `in` should be unambiguously ending the argument list without parsing
issues, shouldn’t it?
-Thorsten
>
> Sent from my iPhone
>
> On Apr 27, 2016, at 1:18 PM, Thorsten Seitz via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>>> Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution
>>> <[email protected] <mailto:[email protected]>>:
>>>
>>> > 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
>>>> <[email protected] <mailto:[email protected]>>:
>>>>
>>>>>
>>>>>> On Apr 26, 2016, at 1:31 PM, Chris Lattner <[email protected]
>>>>>> <mailto:[email protected]>
>>>>>> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Apr 25, 2016, at 11:28 PM, David Owens II via swift-evolution
>>>>>>> <[email protected] <mailto:[email protected]>
>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>
>>>>>>> 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
>>>>> [email protected] <mailto:[email protected]>
>>>>> <mailto:[email protected] <mailto:[email protected]>>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
