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

[Xiaodi Wu]

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 at swift.org> wrote:

> 2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution <
> swift-evolution at 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 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/20161219/4c59cea3/attachment.html>