+1 I’ve tried to write parameter lists like `acc, (valueA, valueB) in` in the past, expecting it to work like this
> On 05 May 2016, at 20:22, Dennis Weissmann via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 > } > > 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. > > 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)) > > 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@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
