Comments below > Am 05.05.2016 um 20:22 schrieb Dennis Weissmann via swift-evolution > <[email protected]>: > > 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
