> Am 27.04.2016 um 14:16 schrieb Vladimir.S via swift-evolution
> <[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]>:
>>
>>>
>>>> On Apr 26, 2016, at 1:31 PM, Chris Lattner <[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]
https://lists.swift.org/mailman/listinfo/swift-evolution
