<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I like the idea of the case let syntax option except for the fact that we have existing syntax for decomposing tuples that doesn’t use case-<div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> (<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">_</span>, age) <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> arg</pre><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">Reusing this syntax feels like a better option than introducing a slight variant of it just for closures-</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(246, 248, 250); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> eighteenOrMore <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> [<span class="pl-s" style="box-sizing: border-box; color: rgb(24, 54, 145);"><span class="pl-pds" style="box-sizing: border-box;">"</span>Tom<span class="pl-pds" style="box-sizing: border-box;">"</span></span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">33</span>, <span class="pl-s" style="box-sizing: border-box; color: rgb(24, 54, 145);"><span class="pl-pds" style="box-sizing: border-box;">"</span>Rebecca<span class="pl-pds" style="box-sizing: border-box;">"</span></span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">17</span>, <span class="pl-s" style="box-sizing: border-box; color: rgb(24, 54, 145);"><span class="pl-pds" style="box-sizing: border-box;">"</span>Siri<span class="pl-pds" style="box-sizing: border-box;">"</span></span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">5</span>].<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">filter</span> { <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> (<span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">_</span>, age) <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">in</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> age <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">>=</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">18</span>
}</pre><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">-Simon</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2 Jun 2017, at 12:25 pm, Tommaso Piazza via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div style="background-color: rgb(255, 255, 255); font-family: 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 13px;" class=""><div id="yui_3_16_0_ym19_1_1496431447786_4791" class=""><span class="">Thanks, added.</span></div> <div class="qtdSeparateBR"><br class=""><br class=""></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;" class=""> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" class=""> <div dir="ltr" class=""><font size="2" face="Arial" class=""> On Friday, June 2, 2017 1:18 PM, Vladimir.S <<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:<br class=""></font></div> <br class=""><br class=""> <div class="y_msg_container"><div dir="ltr" class="">On 02.06.2017 2:34, Tommaso Piazza wrote:<br clear="none" class="">> Is the version you suggest to add to my list for the Swift syntax currently valid as <br clear="none" class="">> of SE-0110 in Swift 4?<br clear="none" class=""><br clear="none" class="">Yes, just checked on latest dev snapshot of Swift 4.<br clear="none" class=""><br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> On Thursday, June 1, 2017 9:32 PM, Vladimir.S <<a shape="rect" ymailto="mailto:svabox@gmail.com" href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:<br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> On 01.06.2017 19:31, Tommaso Piazza wrote:<br clear="none" class="">> > Dear all,<br clear="none" class="">> ><br clear="none" class="">> > I made a comparison of Swift's 4 lack of tuple unsplatting, here is how it stands in<br clear="none" class="">> > comparison with other languages<br clear="none" class="">> ><br clear="none" class="">> > <a shape="rect" href="https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935" target="_blank" class="">https://gist.github.com/blender/53f9568617654c38a219dd4a8353d935</a><br clear="none" class="">> ><br clear="none" class="">> <br clear="none" class="">> Thank you! Very useful information. And also I really like the opinion of<br clear="none" class="">> @AliSoftware in comments for this article.<br clear="none" class="">> <br clear="none" class="">> I'd suggest to add this variant to Swift section in your article:<br clear="none" class="">> <br clear="none" class="">> let eighteenOrMore = ["Tom" : 33, "Rebecca" : 17, "Siri" : 5].filter {<br clear="none" class="">> (arg: (name: String, age: Int)) in arg.age >= 18 }<br clear="none" class="">> <br clear="none" class="">> (I believe it is better that 2 others Swift variants.)<br clear="none" class="">> <br clear="none" class="">> It seems for me that we need to allow some special syntax for *explicit* tuple<br clear="none" class="">> destructuring in closures to make all happy.<br clear="none" class="">> <br clear="none" class="">> FWIW These suggestions are my favorite:<br clear="none" class="">> <br clear="none" class="">> 1. Just allow type inference for tuple's destructured variables in this position:<br clear="none" class="">> <br clear="none" class="">> .filter { (arg: (name, age)) in arg.age >= 18 }<br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> 2. (1) + allow underscore for tuple argument name:<br clear="none" class="">> <br clear="none" class="">> .filter { (_: (name, age)) in age >= 18 }<br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> 3. (2) + allow to omit parenthesis (probably only in case of just one tuple argument)<br clear="none" class="">> <br clear="none" class="">> .filter { _: (name, age) in age >= 18 }<br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> 4. Use pattern matching syntax:<br clear="none" class="">> <br clear="none" class="">> .filter { case let (name, age) in age >= 18 }<br clear="none" class="">> <br clear="none" class="">> (looks similar as allowed today: if case let (name, age) = x { print(name, age) } )<br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> 5. Use two pairs of parenthesis :<br clear="none" class="">> <br clear="none" class="">> .filter { ((name, age)) in age >= 18 }<br clear="none" class="">> <br clear="none" class="">> Btw, about the 5th variant. If took what is allowed today:<br clear="none" class="">> .filter { (arg: (name: String, age: Int)) in arg.age >= 18 }<br clear="none" class="">> , and allow type inference for tuple part arguments, we'll have this:<br clear="none" class="">> .filter { (arg: (name, age)) in arg.age >= 18 }<br clear="none" class="">> , and if additionally allow skipping of tuple argument declaration we'll have:<br clear="none" class="">> .filter { ((name, age)) in arg.age >= 18 }<br clear="none" class="">> I.e. two pairs for parenthesis for tuple destructuring, and such syntax is similar to<br clear="none" class="">> the type this closure should have : ((String, Int)) -> Bool<br clear="none" class="">> <br clear="none" class="">> <br clear="none" class="">> ><br clear="none" class="">> ><br clear="none" class="">> ><br clear="none" class="">> > On Thursday, June 1, 2017 12:25 PM, Vladimir.S via swift-evolution<br clear="none" class="">> > <<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>> wrote:<br clear="none" class="">> ><br clear="none" class="">> ><br clear="none" class="">> > On 01.06.2017 0:42, John McCall wrote:<br clear="none" class="">> > >> On May 31, 2017, at 2:02 PM, Stephen Celis <<a shape="rect" ymailto="mailto:stephen.celis@gmail.com" href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a> <br clear="none" class="">> <mailto:<a shape="rect" ymailto="mailto:stephen.celis@gmail.com" href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a>><br clear="none" class="">> > <mailto:<a shape="rect" ymailto="mailto:stephen.celis@gmail.com" href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a> <mailto:<a shape="rect" ymailto="mailto:stephen.celis@gmail.com" href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a>>>> wrote:<br clear="none" class="">> > >>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution<br clear="none" class="">> > >>> <<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> <br clear="none" class="">> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>>> wrote:<br clear="none" class="">> > >>><br clear="none" class="">> > >>> Yes, I agree. We need to add back tuple destructuring in closure parameter<br clear="none" class="">> > >>> lists because this is a serious usability regression. If we're reluctant to<br clear="none" class="">> > >>> just "do the right thing" to handle the ambiguity of (a,b), we should at least<br clear="none" class="">> > >>> allow it via unambiguous syntax like ((a,b)). I do think that we should just<br clear="none" class="">> > >>> "do the right thing", however, with my biggest concern being whether there's<br clear="none" class="">> > >>> any reasonable way to achieve that in 4.0.<br clear="none" class="">> > >><br clear="none" class="">> > >> Closure parameter lists are unfortunately only half of the equation here. This<br clear="none" class="">> > >> change also regresses the usability of point-free expression.<br clear="none" class="">> > ><br clear="none" class="">> > > The consequences for point-free style were expected and cannot really be<br clear="none" class="">> > > eliminated without substantially weakening SE-0110. Closure convenience seems to<br clear="none" class="">> > > me to be a much more serious regression.<br clear="none" class="">> ><br clear="none" class="">> > John, do you also want to say "and without weakening SE-0066"? Because, if I<br clear="none" class="">> > understand correctly, in this case:<br clear="none" class="">> ><br clear="none" class="">> > func add(_ x: Int, _ y: Int) -> Int {<br clear="none" class="">> > return x + y<br clear="none" class="">> > }<br clear="none" class="">> ><br clear="none" class="">> > zip([1, 2, 3], [4, 5, 6]).map(add)<br clear="none" class="">> ><br clear="none" class="">> > .. we have a clear function type mismatch situation, when map() expects function of<br clear="none" class="">> > type ((Int, Int))->Int, but function of type (Int,Int)->Int is provided ? So probably<br clear="none" class="">> > the additional 'reason' of the 'problem' in this case is SE-0066, no?<br clear="none" class="">> > Or I don't understand the SE-0066 correctly..<br clear="none" class="">> > Do we want to allow implicit conversions between function type ((Int,Int))->Int and<br clear="none" class="">> > (Int,Int)->Int?<br clear="none" class="">> ><br clear="none" class="">> > Quote from SE-0066:<br clear="none" class="">> > ---<br clear="none" class="">> > (Int, Int) -> Int // function from Int and Int to Int<br clear="none" class="">> > ((Int, Int)) -> Int // function from tuple (Int, Int) to Int<br clear="none" class="">> > ---<br clear="none" class="">> ><br clear="none" class="">> > During this discussion I see a wish of some group of developers to just return back<br clear="none" class="">> > tuple splatting for function/closure arguments, so they can freely send tuple to<br clear="none" class="">> > function/closure accepting a list of parameters(and probably vise-versa).<br clear="none" class="">> > Is it worth to follow SE-0066 and SE-0110 as is, i.e. disallow tuple deconstructing<br clear="none" class="">> > and then, as additive change improve the situation with tuple<br clear="none" class="">> > splatting/deconstructing later with separate big proposal?<br clear="none" class="">> ><br clear="none" class="">> > Btw, about the SE-0110 proposal. It was discussed, formally reviewed and accepted. I<br clear="none" class="">> > expect that its revision also should be formally proposed/reviewed/accepted to<br clear="none" class="">> > collect a wide range of opinions and thoughts, and attract the attention of<br clear="none" class="">> > developers in this list to the subject.<br clear="none" class="">> ><br clear="none" class="">> ><br clear="none" class="">> > Also, if we revisit SE-0110, will this code be allowed?:<br clear="none" class="">> ><br clear="none" class="">> > func foo(_ callback: ((Int,Int))->Void) {}<br clear="none" class="">> > let mycallback = {(x:Int, y:Int)->Void in }<br clear="none" class="">> > foo(mycallback)<br clear="none" class="">> ><br clear="none" class="">> > and<br clear="none" class="">> ><br clear="none" class="">> > func foo(_ callback: (Int,Int)->Void) {}<br clear="none" class="">> > let mycallback = {(x: (Int, Int))->Void in }<br clear="none" class="">> > foo(mycallback)<br clear="none" class="">> ><br clear="none" class="">> > If so, what will be result of this for both cases? :<br clear="none" class="">> ><br clear="none" class="">> > print(type(of:mycallback)) // (Int,Int)->Void or ((Int,Int))->Void<br clear="none" class="">> ><br clear="none" class="">> > If allowed, do we want to allow implicit conversion between types (Int,Int)->Void and<br clear="none" class="">> > ((Int,Int))->Void in both directions? (Hello tuple splatting?)<br clear="none" class="">> ><br clear="none" class="">> ><br clear="none" class="">> > ><br clear="none" class="">> > > John.<br clear="none" class="">> > ><br clear="none" class="">> > ><br clear="none" class="">> > >><br clear="none" class="">> > >> func add(_ x: Int, _ y: Int) -> Int { return x + y }<br clear="none" class="">> > >><br clear="none" class="">> > >> zip([1, 2, 3], [4, 5, 6]).map(add)<br clear="none" class="">> > >><br clear="none" class="">> > >> // error: nested tuple parameter '(Int, Int)' of function '(((_.Element,<br clear="none" class="">> > >> _.Element)) throws -> _) throws -> [_]' does not support destructuring<br clear="none" class="">> > >><br clear="none" class="">> > >> This may not be a common pattern in most projects, but we heavily use this style<br clear="none" class="">> > >> in the Kickstarter app in our functional and FRP code. Definitely not the most<br clear="none" class="">> > >> common coding pattern, but a very expressive one that we rely on.<br clear="none" class="">> > >><br clear="none" class="">> > >> Our interim solution is a bunch of overloaded helpers, e.g.:<br clear="none" class="">> > >><br clear="none" class="">> > >> func tupleUp<A, B, C>(_ f: (A, B) -> C) -> ((A, B)) -> C { return }<br clear="none" class="">> > >><br clear="none" class="">> > >> zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))<br clear="none" class="">> > >><br clear="none" class="">> > >> Stephen<br clear="none" class="">> > ><br clear="none" class="">> > > .<br clear="none" class="">> > ><br clear="none" class="">> > _______________________________________________<br clear="none" class="">> > swift-evolution mailing list<div class="yqt9433621530" id="yqtfd45114"><br clear="none" class="">> > <a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> <br clear="none" class="">> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <mailto:<a shape="rect" ymailto="mailto:swift-evolution@swift.org" href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>><br clear="none" class="">> <br clear="none" class="">> > <a shape="rect" href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br clear="none" class="">> ><br clear="none" class="">> ><br clear="none" class="">> <br clear="none" class="">> <br clear="none" class=""></div></div><br class=""><br class=""></div> </div> </div> </div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>