Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses


(Vip Malixi) #1

When using Closures in Swift, you declare the parameter names inside the curly brackets. How come for tuples you don't, but declare them outside? Also, why do single parameters not need parentheses? This makes Swift inconsistent, e.g.
var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = { numbers -> ([Int], [Int]) in var evenNumberArray = [Int]() var oddNumberArray = [Int]()
for number in numbers { number % 2 == 0 ? evenNumberArray.append(number) : oddNumberArray.append(number) }
return (evenNumberArray, oddNumberArray)}
for consistency, I suggest tuple names should be in curly brackets where you also declare parameter names. Also, again for consistency and clarity, parameters in Closures should always be surrounded by parentheses, even single parameters:
var oneParameterAndMultipleReturn: ([Int]) -> ([Int], [Int]) = { (numbers) -> (even:[Int], odd:[Int]) in var evenNumberArray = [Int]() var oddNumberArray = [Int]()
for number in numbers { number % 2 == 0 ? evenNumberArray.append(number) : oddNumberArray.append(number) }
return (evenNumberArray, oddNumberArray)}


(Anton Zhilin) #2

var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = {

numbers -> ([Int], [Int]) in
    var evenNumberArray = [Int]()
    var oddNumberArray = [Int]()

    for number in numbers {
        number % 2 == 0 ? evenNumberArray.append(number) :
oddNumberArray.append(number)
    }

    return (evenNumberArray, oddNumberArray)
}

The above code is valid, because:

   1. Multi-return is just a type of tuple with labeled components.
   2. Labeled tuples and normal tuples are implicitly convertible.

The only way we could make such code invalid is by removing labeled tuples
altogether. -1 on that.
This problem mostly refers to code style, and the above variant can be more
self-documenting in some cases.

Also, again for consistency and clarity, parameters in Closures should

always be surrounded by parentheses, even single parameters:

var oneParameterAndMultipleReturn: ([Int]) -> ([Int], [Int]) = { (numbers)
-> (even:[Int], odd:[Int]) in
    var evenNumberArray = [Int]()
    var oddNumberArray = [Int]()

    for number in numbers {
        number % 2 == 0 ? evenNumberArray.append(number) :
oddNumberArray.append(number)
    }

    return (evenNumberArray, oddNumberArray)
}

This should be considered a bug. numbers in or (numbers) in or (numbers) ->
(...) in, but not numbers -> (...) in, because the latter forms should be
correct types.
Whether or not just numbers in should be allowed, is another talk.

···

2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution < swift-evolution@swift.org>:


(Xiaodi Wu) #3

This issue about `numbers in` was raised during review of SE-0066; if I
recall, the core team considered and rejected disallowing that syntax in
closures. Since we're minimizing source-breaking changes, the issue is
settled in my view, having been proposed, commented upon, reviewed, and
rejected.

···

On Mon, Dec 19, 2016 at 15:39 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution <
swift-evolution@swift.org>:

var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = {
numbers -> ([Int], [Int]) in
    var evenNumberArray = [Int]()
    var oddNumberArray = [Int]()

    for number in numbers {
        number % 2 == 0 ? evenNumberArray.append(number) :
oddNumberArray.append(number)
    }

    return (evenNumberArray, oddNumberArray)
}

The above code is valid, because:

   1. Multi-return is just a type of tuple with labeled components.
   2. Labeled tuples and normal tuples are implicitly convertible.

The only way we could make such code invalid is by removing labeled tuples
altogether. -1 on that.
This problem mostly refers to code style, and the above variant can be
more self-documenting in some cases.

Also, again for consistency and clarity, parameters in Closures should
always be surrounded by parentheses, even single parameters:

var oneParameterAndMultipleReturn: ([Int]) -> ([Int], [Int]) = { (numbers)
-> (even:[Int], odd:[Int]) in
    var evenNumberArray = [Int]()
    var oddNumberArray = [Int]()

    for number in numbers {
        number % 2 == 0 ? evenNumberArray.append(number) :
oddNumberArray.append(number)
    }

    return (evenNumberArray, oddNumberArray)
}

This should be considered a bug. numbers in or (numbers) in or (numbers)
-> (...) in, but not numbers -> (...) in, because the latter forms should
be correct types.
Whether or not just numbers in should be allowed, is another talk.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Derrick Ho) #4

The core team designed swift blocks to range from concise to verbose. Which
one you use depends on your needs.

If you want to write parenthesis then by all means write parenthesis; no
one is stopping you.

I would rather keep the block syntax as it is so that everyone can choose
the style that matches their needs.

···

On Mon, Dec 19, 2016 at 1:52 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

This issue about `numbers in` was raised during review of SE-0066; if I
recall, the core team considered and rejected disallowing that syntax in
closures. Since we're minimizing source-breaking changes, the issue is
settled in my view, having been proposed, commented upon, reviewed, and
rejected.
On Mon, Dec 19, 2016 at 15:39 Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote:

2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution <
swift-evolution@swift.org>:

var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = {
numbers -> ([Int], [Int]) in
    var evenNumberArray = [Int]()
    var oddNumberArray = [Int]()

    for number in numbers {
        number % 2 == 0 ? evenNumberArray.append(number) :
oddNumberArray.append(number)
    }

    return (evenNumberArray, oddNumberArray)
}

The above code is valid, because:

   1. Multi-return is just a type of tuple with labeled components.

   2. Labeled tuples and normal tuples are implicitly convertible.

The only way we could make such code invalid is by removing labeled tuples
altogether. -1 on that.
This problem mostly refers to code style, and the above variant can be
more self-documenting in some cases.

Also, again for consistency and clarity, parameters in Closures should
always be surrounded by parentheses, even single parameters:

var oneParameterAndMultipleReturn: ([Int]) -> ([Int], [Int]) = { (numbers)
-> (even:[Int], odd:[Int]) in
    var evenNumberArray = [Int]()
    var oddNumberArray = [Int]()

    for number in numbers {
        number % 2 == 0 ? evenNumberArray.append(number) :
oddNumberArray.append(number)
    }

    return (evenNumberArray, oddNumberArray)
}

This should be considered a bug. numbers in or (numbers) in or (numbers)
-> (...) in, but not numbers -> (...) in, because the latter forms should
be correct types.
Whether or not just numbers in should be allowed, is another talk.

_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list

swift-evolution@swift.org

https://lists.swift.org/mailman/listinfo/swift-evolution


(Anton Zhilin) #5

The core team designed swift blocks to range from concise to verbose. Which

one you use depends on your needs.

If you want to write parenthesis then by all means write parenthesis; no
one is stopping you.

I would rather keep the block syntax as it is so that everyone can choose
the style that matches their needs.

This issue about `numbers in` was raised during review of SE-0066; if I
recall, the core team considered and rejected disallowing that syntax in
closures. Since we're minimizing source-breaking changes, the issue is
settled in my view, having been proposed, commented upon, reviewed, and
rejected.

Ok, I understand, you probably consider the syntax in question { param ->

Int in ... } closer to the short form { param in ... } than to the full
form { (param: Int) -> Int in ... }

So when applying analogy, it makes more sense to allow the omission as in
the short form than to disallow as in the full form. I have to agree. So,
-1 to all points of the OP.

···

2016-12-20 0:59 GMT+03:00 Derrick Ho <wh1pch81n@gmail.com>:

On Mon, Dec 19, 2016 at 1:52 PM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:


(Vip Malixi) #6

Choice for choice's sake as in 100s of ways to do the same thing leads to confusion and complexity. My suggestions are to make Swift consistent, simple, and clear. As it is right now, the motives to keep things status quo in Swift are the same reasons MS Windows was more difficult to use than the Mac OS: hundreds of unintuitive ways to do the same thing added by programmers without concern for simplicity, ease-of-use and elegance.
V. Malixi

···

From: Anton Zhilin <antonyzhilin@gmail.com>
To: Derrick Ho <wh1pch81n@gmail.com>
Cc: Vip Malixi <vip_m@yahoo.com>; Xiaodi Wu <xiaodi.wu@gmail.com>; "swift-evolution@swift.org" <swift-evolution@swift.org>
Sent: Tuesday, December 20, 2016 6:15 AM
Subject: Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses
   
2016-12-20 0:59 GMT+03:00 Derrick Ho <wh1pch81n@gmail.com>:
The core team designed swift blocks to range from concise to verbose. Which one you use depends on your needs.

If you want to write parenthesis then by all means write parenthesis; no one is stopping you.

I would rather keep the block syntax as it is so that everyone can choose the style that matches their needs.
On Mon, Dec 19, 2016 at 1:52 PM Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

This issue about `numbers in` was raised during review of SE-0066; if I recall, the core team considered and rejected disallowing that syntax in closures. Since we're minimizing source-breaking changes, the issue is settled in my view, having been proposed, commented upon, reviewed, and rejected.

Ok, I understand, you probably consider the syntax in question { param -> Int in ... } closer to the short form { param in ... } than to the full form { (param: Int) -> Int in ... }So when applying analogy, it makes more sense to allow the omission as in the short form than to disallow as in the full form. I have to agree. So, -1 to all points of the OP.​