I have a different read of the proposal I guess... I actually find that this:
(Int, Int) -> (Int, Int)
Naturally reads take a single pair (e.g. tuple) of (Int, Int) and return a
single pair of (Int, Int)
This actually looks and feels like the right implementation to me:
let tx: (Int, Int) -> (Int, Int) = { ($0.1, $0.0) }
And I am saying that this would be explicitly wrong:
let tx: (Int, Int) -> (Int, Int) = { ($1, $0) }
If I wanted a type signature of that took two Int params, I would expect to
write this:
let tx: Int, Int -> (Int, Int) = { ($1, $0) }
That reads, a type signature that takes two Int values and returns a single
(Int, Int) pair.
The problem, to me at least, is that the function declaration overloads the
meaning of () as "start of parameter list for function declaration".
func tx((Int, Int)) -> (Int, Int) { return ($0.1, $0.0) }
So now you have this mess to say the same thing: take a single pair of Int and
return a pair of Int.
Similarly, if the () are going to required for parameter lists in function
declarations, I really struggle to see why these two forms should mean the same
thing:
y = x.sorted { (lhs, rhs) in rhs < lhs }
y = x.sorted { lhs, rhs in rhs < lhs }
Dropping the type signatures because that can be inferred is one thing, but
changing the structure of the parameter list seems like an orthogonal
optimization.
y = x.sorted { (lhs : Int, rhs : Int) -> Bool in rhs < lhs }
y = x.sorted { (lhs, rhs) in rhs < lhs }
{ $1 < $0 }
This process keeps the structural elements while dropping all of the type
pieces and maintains the consistency that in function types (regardless of how
they are defined), the () denotes a parameter list. If you actually want a
tuple within the parameter list, you need to do `((lhs, rhs))`.
-David
> On Apr 19, 2016, at 9:24 AM, Erica Sadun via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Apr 19, 2016, at 9:44 AM, David Rönnqvist <david.ronnqv...@gmail.com
>> <mailto:david.ronnqv...@gmail.com>> wrote:
>>
>> Would this also affect the syntax for naming closure arguments? For example,
>> would this (taken from "The Swift Programming Language (Swift 2.2)”):
>> reversed = names.sort( { s1, s2 in return s1 > s2 } )
>> have to be written like this:
>> reversed = names.sort( { (s1, s2) in return s1 > s2 } )
>> or is that a different syntax?
>>
>> As a developer focused on _writing_ and _reading_ code like this, I don’t
>> see the real benefits of this change. It only feels natural to me that I
>> would be able to omit the parentheses when there is only one type, but that
>> I would need them to group multiple arguments or to label arguments.
>>
>> That said, I don’t feel strongly about it and the work of transitioning our
>> code would be minimal. If this change provides other engineering benefits
>> that aren’t noticeable on the surface, then I’m positive to the change for
>> those reasons.
>>
>> - David
>
> It would not affect the closure syntax. To paraphrase Chris:
> No. Swift’s syntactic shortcuts in its closure parameter lists benefit simple
> functional algorithms. Few people would choose to write fully specified
> long-form declarations when, for example, reverse-sorting an array of
> integers:
>
> y = x.sorted { (lhs : Int, rhs : Int) -> Bool in rhs < lhs }
> Compare the long form with this simpler form:
>
> y = x.sorted { lhs, rhs in rhs < lhs }
> You can use the even shorter form of { $1 < $0 }.
>
> Closures offer a structurally distinct class of syntactic sugar:
>
> You may elide parentheses (even with multiple arguments)
> You may omit the return type
> You may omit types
> You may omit the parameter list in its entirety
> Short of a complete rethink of closure syntax, requiring parentheses there
> would not improve the language in any measurable way.
>
> _______________________________________________
> 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
