[swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Geordie J]

Comments below

> Am 05.05.2016 um 20:22 schrieb Dennis Weissmann via swift-evolution <swift-evolution at swift.org>:
> 
> Following a short discussion with positive feedback on [swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812 <http://thread.gmane.org/gmane.comp.lang.swift.user/1812>) I’d like to discuss the following:
> 
> Tuples should be destructible into their components in parameter lists.
> 
> Consider the following code:
> 
> let a = [0,1,2,3,4,5,6,7,8,9]
> let b = [0,1,2,3,4,5,6,7,8,9]
> 
> let c = zip(a,b).reduce(0) { acc, tuple in
>   acc + tuple.0 + tuple.1
> }
> 
> tuple is of type (Int, Int).
> 
> The problem is that the calculation is not very comprehensible due to .0 and .1. That’s when destructuring tuples directly in the parameter list comes into play:
> 
> let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
>   acc + valueA + valueB
> }

+1 I think this is a great way to go about it.

> 
> The above is what I propose should be accepted by the compiler (but currently isn’t).
> 
> Currently tuple destructuring is possible like this:
> 
> let c = zip(a,b).reduce(0) { (acc, tuple) in
>   let (valueA, valueB) = tuple
>   return acc + valueA + valueB
> }
> 
> This is not about saving one line ;-). I just find it much more intuitive to destructure the tuple in the parameter list itself.

Agreed

> 
> The same thing could be done for functions:
> 
> func takesATuple(someInt: Int, tuple: (String, String))
> 
> Here we also need to destructure the tuple inside the function, but the intuitive place (at least for me) to do this would be the parameter list.
> 
> In the following example I'm making use of Swift’s feature to name parameters different from their labels (for internal use inside the function, this is not visible to consumers of the API):
> 
> func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))


I’m not such a fan of this though. I realize what I’m about to write here is discussing a slightly different point but bear with me: I was under the impression it was already possible to do something like this (maybe only possible with typealiases):

func takesATuple(someInt: Int, tuple: (valueA: String, valueB: String)) {}

I find that syntax readable and extensible: you can make a type alias for your tuple type '(valueA: String, valueB: String)‘, you can then use it like this:

func takesATuple(someInt: Int, tuple: MyAliasedTupleType) {
  print(tuple.valueA)
}

It’s true that you still have the ‚overhead‘ of having to type tuple. before accessing its members. But this is almost always what I want (hopefully you’d never actually name your tuple ‚tuple‘, instead it’d be a logical namespace for what it contains). Do you have a real-world example where you’d need this? To me it seems that in a case like this the API that produced the tuple would need refining rather than the language itself.

> 
> Here valueA and valueB would be directly usable within the function. The tuple as a whole would not be available anymore.
> 
> 
> Now it’s your turn!
> 
> 1. What do you think?
> 2. Is this worth being discussed now (i.e. is it implementable in the Swift 3 timeframe) or should I delay it?
> 
> Cheers,
> 
> - Dennis
> _______________________________________________
> 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/20160508/1242a2eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160508/1242a2eb/attachment.sig>