Sent from my iPad
> On Apr 19, 2016, at 1:24 PM, David Owens II via swift-evolution > <[email protected]> wrote: > > 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, you make some great points about potential for confusion around tuples vs parentheses around the parameter list. This is a great argument for only using them when we explicitly intend to specify a tuple rather than allowing them for the argument list. > > -David > >>> On Apr 19, 2016, at 9:24 AM, Erica Sadun via swift-evolution >>> <[email protected]> wrote: >>> >>> >>> On Apr 19, 2016, at 9:44 AM, David Rönnqvist <[email protected]> >>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
