<div dir="ltr">I, for one, would be willing to accept Xiaodi's suggestion involving `let`–especially if (pipe dream follows) we could use the same syntax in functions/methods to destructure parameters.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 1, 2017 at 3:32 PM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01.06.2017 19:31, Tommaso Piazza wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear all,<br>
<br>
I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it stands in comparison with other languages<br>
<br>
<a href="https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935" rel="noreferrer" target="_blank">https://gist.github.com/blende<wbr>r/53f9568617654c38a219dd4a8353<wbr>d935</a><br>
<br>
</blockquote>
<br></span>
Thank you! Very useful information. And also I really like the opinion of @AliSoftware in comments for this article.<br>
<br>
I'd suggest to add this variant to Swift section in your article:<br>
<br>
let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {<br>
(arg: (name: String, age: Int)) in arg.age >= 18 }<br>
<br>
(I believe it is better that 2 others Swift variants.)<br>
<br>
It seems for me that we need to allow some special syntax for *explicit* tuple destructuring in closures to make all happy.<br>
<br>
FWIW These suggestions are my favorite:<br>
<br>
1. Just allow type inference for tuple's destructured variables in this position:<br>
<br>
.filter { (arg: (name, age)) in arg.age >= 18 }<br>
<br>
<br>
2. (1) + allow underscore for tuple argument name:<br>
<br>
.filter { (_: (name, age)) in age >= 18 }<br>
<br>
<br>
3. (2) + allow to omit parenthesis (probably only in case of just one tuple argument)<br>
<br>
.filter { _: (name, age) in age >= 18 }<br>
<br>
<br>
4. Use pattern matching syntax:<br>
<br>
.filter { case let (name, age) in age >= 18 }<br>
<br>
(looks similar as allowed today: if case let (name, age) = x { print(name, age) } )<br>
<br>
<br>
5. Use two pairs of parenthesis :<br>
<br>
.filter { ((name, age)) in age >= 18 }<br>
<br>
Btw, about the 5th variant. If took what is allowed today:<br>
.filter { (arg: (name: String, age: Int)) in arg.age >= 18 }<br>
, and allow type inference for tuple part arguments, we'll have this:<br>
.filter { (arg: (name, age)) in arg.age >= 18 }<br>
, and if additionally allow skipping of tuple argument declaration we'll have:<br>
.filter { ((name, age)) in arg.age >= 18 }<br>
I.e. two pairs for parenthesis for tuple destructuring, and such syntax is similar to the type this closure should have : ((String, Int)) -> Bool<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
<br>
On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
<br>
On 01.06.2017 0:42, John McCall wrote:<br></span><span class="">
>> On May 31, 2017, at 2:02 PM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.com</a> <mailto:<a href="mailto:stephen.celis@gmail.com" target="_blank">stephen.celis@gmail.co<wbr>m</a>>> wrote:<br>
>>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution<br></span><div><div class="h5">
>>> <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
>>><br>
>>> Yes, I agree. We need to add back tuple destructuring in closure parameter<br>
>>> lists because this is a serious usability regression. If we're reluctant to<br>
>>> just "do the right thing" to handle the ambiguity of (a,b), we should at least<br>
>>> allow it via unambiguous syntax like ((a,b)). I do think that we should just<br>
>>> "do the right thing", however, with my biggest concern being whether there's<br>
>>> any reasonable way to achieve that in 4.0.<br>
>><br>
>> Closure parameter lists are unfortunately only half of the equation here. This<br>
>> change also regresses the usability of point-free expression.<br>
><br>
> The consequences for point-free style were expected and cannot really be<br>
> eliminated without substantially weakening SE-0110. Closure convenience seems to<br>
> me to be a much more serious regression.<br>
<br>
John, do you also want to say "and without weakening SE-0066"? Because, if I<br>
understand correctly, in this case:<br>
<br>
func add(_ x: Int, _ y: Int) -> Int {<br>
return x + y<br>
}<br>
<br>
zip([1, 2, 3], [4, 5, 6]).map(add)<br>
<br>
.. we have a clear function type mismatch situation, when map() expects function of<br>
type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So probably<br>
the additional 'reason' of the 'problem' in this case is SE-0066, no?<br>
Or I don't understand the SE-0066 correctly..<br>
Do we want to allow implicit conversions between function type ((Int,Int))->Int and<br>
(Int,Int)->Int?<br>
<br>
Quote from SE-0066:<br>
---<br>
(Int, Int) -> Int // function from Int and Int to Int<br>
((Int, Int)) -> Int // function from tuple (Int, Int) to Int<br>
---<br>
<br>
During this discussion I see a wish of some group of developers to just return back<br>
tuple splatting for function/closure arguments, so they can freely send tuple to<br>
function/closure accepting a list of parameters(and probably vise-versa).<br>
Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple deconstructing<br>
and then, as additive change improve the situation with tuple<br>
splatting/deconstructing later with separate big proposal?<br>
<br>
Btw, about the SE-0110 proposal. It was discussed, formally reviewed and accepted. I<br>
expect that its revision also should be formally proposed/reviewed/accepted to<br>
collect a wide range of opinions and thoughts, and attract the attention of<br>
developers in this list to the subject.<br>
<br>
<br>
Also, if we revisit SE-0110, will this code be allowed?:<br>
<br>
func foo(_ callback: ((Int,Int))->Void) {}<br>
let mycallback = {(x:Int, y:Int)->Void in }<br>
foo(mycallback)<br>
<br>
and<br>
<br>
func foo(_ callback: (Int,Int)->Void) {}<br>
let mycallback = {(x: (Int, Int))->Void in }<br>
foo(mycallback)<br>
<br>
If so, what will be result of this for both cases? :<br>
<br>
print(type(of:mycallback)) // (Int,Int)->Void or ((Int,Int))->Void<br>
<br>
If allowed, do we want to allow implicit conversion between types (Int,Int)->Void and<br>
((Int,Int))->Void in both directions? (Hello tuple splatting?)<br>
<br>
<br>
><br>
> John.<br>
><br>
><br>
>><br>
>> func add(_ x: Int, _ y: Int) -> Int { return x + y }<br>
>><br>
>> zip([1, 2, 3], [4, 5, 6]).map(add)<br>
>><br>
>> // error: nested tuple parameter '(Int, Int)' of function '(((_.Element,<br>
>> _.Element)) throws -> _) throws -> [_]' does not support destructuring<br>
>><br>
>> This may not be a common pattern in most projects, but we heavily use this style<br>
>> in the Kickstarter app in our functional and FRP code. Definitely not the most<br>
>> common coding pattern, but a very expressive one that we rely on.<br>
>><br>
>> Our interim solution is a bunch of overloaded helpers, e.g.:<br>
>><br>
>> func tupleUp<A, B, C>(_ f: (A, B) -> C) -> ((A, B)) -> C { return }<br>
>><br>
>> zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))<br>
>><br>
>> Stephen<br>
><br>
> .<br>
><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
</div></div><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>