+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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
