[Pitch] Tuple Destructuring in Parameter Lists


(Thorsten Seitz) #1

+1

I do like the syntax suggested by Dennis. Making use of Swift's ability to differentiate between external and internal parameter names is a great idea!

-Thorsten

···

Am 06. Mai 2016 um 06:25 schrieb "T.J. Usiyan via swift-evolution" <swift-evolution@swift.org>:

+1
I have wanted this since the first beta. I hadn't proposed because I haven't come up with a nice syntax to do this in functions/methods. I don't particularly like
func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))

and the closes that I have come is to simply reuse the closure syntax with

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

but that gets confusing in my opinion, specifically if you choose to have different names inside and outside.

On Thu, May 5, 2016 at 11:22 AM, 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) 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


(Goffredo Marocchi) #2

+1 it improves readability a lot and thus should be encouraged.

[[iOS messageWithData:ideas] broadcast]

···

On 6 May 2016, at 07:57, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

+1

I do like the syntax suggested by Dennis. Making use of Swift's ability to differentiate between external and internal parameter names is a great idea!

-Thorsten

Am 06. Mai 2016 um 06:25 schrieb "T.J. Usiyan via swift-evolution" <swift-evolution@swift.org>:

+1
I have wanted this since the first beta. I hadn't proposed because I haven't come up with a nice syntax to do this in functions/methods. I don't particularly like
    func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))

and the closes that I have come is to simply reuse the closure syntax with

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

but that gets confusing in my opinion, specifically if you choose to have different names inside and outside.

On Thu, May 5, 2016 at 11:22 AM, 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) 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Cole Campbell) #3

+1 from me as well. I have no problem with the function declaration in the example. It's very intuitive and is much more elegant than destructing in the function body.

Cole

···

On May 6, 2016, at 2:05 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

+1 it improves readability a lot and thus should be encouraged.

[[iOS messageWithData:ideas] broadcast]

On 6 May 2016, at 07:57, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

+1

I do like the syntax suggested by Dennis. Making use of Swift's ability to differentiate between external and internal parameter names is a great idea!

-Thorsten

Am 06. Mai 2016 um 06:25 schrieb "T.J. Usiyan via swift-evolution" <swift-evolution@swift.org>:

+1
I have wanted this since the first beta. I hadn't proposed because I haven't come up with a nice syntax to do this in functions/methods. I don't particularly like
    func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))

and the closes that I have come is to simply reuse the closure syntax with

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

but that gets confusing in my opinion, specifically if you choose to have different names inside and outside.

On Thu, May 5, 2016 at 11:22 AM, 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) 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

_______________________________________________
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