<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Ever considered looking at how typescript handles argument names in object literal deconstruction?<br><br><div>Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div><br>On Jul 3, 2016, at 10:36 PM, Pyry Jahkola via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite" class="">On 30 Jun 2016, Chris Lattner wrote:<br class=""></blockquote><blockquote type="cite" class=""><br class="">The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a></blockquote><blockquote type="cite" class=""><br class="">What is your evaluation of the proposal?<br class=""></blockquote><div class=""><br class=""></div><div class="">+1. With the way the community has settled using argument labels, it seems clear to me that argument labels are part of a function's name and should not affect its type.</div><div class=""><br class=""></div><div class="">What we currently have <i class="">technically</i> works because the compiler is quite lenient in type conversions between different argument labels. But since there are corner cases lurking where labels in the function type matter (as demonstrated in the proposal), it's best we get rid of them entirely for clarity. As it has been pointed out, the status quo also complicates the overload resolution process and causes confusing error messages when the compiler can't tell if your argument <i class="">labels</i> are wrong or argument <i class="">types</i>. We're better without that complexity.</div><div class=""><br class=""></div><div class="">Further, I think removing this oddity could make function application with tuples feasible <i class="">again</i> (a.k.a the simple form of "tuple splatting" with all arguments in the tuple) by requiring to fully name the function before passing the arguments tuple:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> <b class="">func</b> doSomething(x: Int, y: Int) -> Bool { <b class="">return</b> <b class="">true</b> }</font></div><div class=""><font face="Menlo" class=""> <b class="">func</b> doSomething(any: Any) -> Bool { <b class="">return</b> <b class="">false</b> } <font color="#919191" class="">// This can't possibly be considered below.</font></font></div><div class=""><font face="Menlo" class=""> </font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> args = (1, 2)</font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> named = (x: 1, y: 2)</font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> f = doSomething(x:y:)</font></div><div class=""><font face="Menlo" class=""> f(args) <font color="#919191" class="">// Unambiguous call, if the syntax is made legal (again).</font></font></div><div class=""><font face="Menlo" class=""> doSomething(x:y:)(args) <font color="#919191" class="">// So is this.</font></font></div><div class=""><font face="Menlo" class=""><font color="#919191" class=""> </font><font color="#ff2600" class="">doSomething(args)</font><font color="#919191" class=""> // This would still be an error as per </font></font><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md" class=""><font face="Menlo" class="">SE-0029</font></a><font face="Menlo" class=""><font color="#919191" class="">.</font></font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> tuples = [(1, 2), (3, 4), (5, 6)]</font></div><div class=""><font face="Menlo" class=""> print(tuples.map(f))</font><span style="font-family: Menlo;" class=""> </span><font color="#919191" style="font-family: Menlo;" class="">// This would be allowed. (Confusingly it already works despite SE-0029!)</font></div><div class=""><br class=""></div><div class="">In particular, you couldn't apply a `<font face="Menlo" class=""><b class="">func</b></font>` function with a tuple (which was what SE-0029 removed) but you <i class="">could</i> apply a qualified function reference (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md" class="">SE-0021</a>) as well as a function value (i.e. a named closure) with a tuple, because both of them have set in stone their argument list length before the tuple application and thus suffer from none of the disadvantages listed in the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#motivation" class="">motivation for SE-0029</a>. That would of course need a separate proposal and can be delayed until Swift 3 has been released.</div><div class=""><br class=""></div><blockquote type="cite" class="">Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><div class=""><br class=""></div><div class="">Yes.</div><br class=""><blockquote type="cite" class="">Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote><div class=""><br class=""></div><div class="">I think so.</div><br class=""><blockquote type="cite" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote><div class=""><br class=""></div><div class="">Well, we've had argument labels in Objective-C but since it's not a strongly typed language I don't think it applies for comparison. However, I naturally feel argument labels in Objective-C as well are part of the function's name rather than its type.</div><div class=""><br class=""></div><blockquote type="cite" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><div class=""><br class=""></div><div class="">More than a quick reading. I've suggested a similar idea before but didn't motivate it well enough to gain interest back then. Big thanks to Austin for driving it forward this time!</div><div class=""><br class=""></div><span style="font-size: 12px;" class="">—</span> Pyry<br class=""><br class=""><div class=""><div class="">PS. Can anybody explain why the last example in my code above turned out to be allowed even though SE-0029 seems to prohibit it? Here's a more comprehensive test which made me positively surprised that it still worked after SE-0029:</div></div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> <b class="">let</b> f: (Int, Int) -> Int = (+)</font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> x = (1, 2)</font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> x, y = (3, 4)</font></div><div class=""><font face="Menlo" class=""> f(1, 2) <font color="#919191" class="">//=> 3</font></font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// f((1, 2)) // Does not compile, as expected (SE-0029).</font></font></div><div class=""><font face="Menlo" class=""> <font color="#919191" class="">// f(x) // Does not compile, as expected.</font></font></div><div class=""><font face="Menlo" class=""> [x, y].map(f) <font color="#919191" class="">//=> [3, 7] // Surprisingly compiles, but why?</font></font></div><div class=""><font face="Menlo" class=""> <b class="">let</b> g: ((Int, Int)) -> Int = f </font><span style="color: rgb(145, 145, 145); font-family: Menlo;" class="">// Huh? </span><span style="color: rgb(145, 145, 145); font-family: Menlo;" class="">So `f` can coerce to a `(tuple) -> Int`?</span></div><div class=""><span style="font-family: Menlo;" class=""> g(x) </span><font color="#919191" style="font-family: Menlo;" class="">//=> 3 // So this is what made `map` work above.</font></div><div class=""><font face="Menlo" class=""> (f <b class="">as</b> ((Int, Int)) -> Int)(x) <font color="#919191" class="">//=> 3 // This works too, didn't expect it to.</font></font></div><div class=""><div class=""><font face="Menlo" class=""> [x, y].map(+) <font color="#919191" class="">//=> [3, 7] // Finally, why is this allowed despite SE-0029?</font></font></div></div><div class=""><font face="Menlo" class=""><font color="#919191" class=""><br class=""></font></font></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>