<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 2, 2016, at 12:59 PM, Joe Groff 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Yeah, I'm with Greg—I don't think this saves much over an explicit closure with $N arguments. Another problem with '_' is that it's nonobvious what the boundaries of the closure should be. You can say that it's the enclosing function application, but in the AST, a method invocation is two function applications, so by that rule '_.foo(_)' would mean {{ $0.foo }($0)}, and every operator is a separate function call, so '_ + _ + _' would be '{{ $0 + $1 } + $0}', neither of which is likely to be expected. The { $N } syntax is almost as compact, and is both clearer and more general.</div></div></blockquote><div><br class=""></div><div>I generally agree that specific syntax for partial application is not necessary. The {} wrapping the closure is not burdensome enough to justify a special case feature for partial application.</div><div><br class=""></div><div>However, I am not a huge fan of the $N placeholder syntax. It looks noisy and also gets lost in the rest of the expression much more than underscore(s). `_` leaves visual “whitespace” which makes the “hole” in the expression stand out. </div><div><br class=""></div><div>I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder. I wonder if there has been confusion about the semantics <b class="">in practice</b> in languages like Scala where it is used in both ways. Is there any evidence that this has been a problem?</div><div><br class=""></div><div>I would like to see us consider switching to the the approach Dave posted:</div><div><br class=""></div><div><blockquote type="cite" class="">Other systems have used “_”, and, for reordering parameters, “_0”,<br class="">“_1”, ...<br class=""><br class="">let partial1 = f(arg1: 1, arg2: _) // { f(arg1: 1, arg2: $0) }<br class="">let partial2 = f(arg1: _1, arg2: _0) // { f(arg1: $1, arg2: $0) }</blockquote></div><div><br class=""></div><div>Naked `_` would refer arguments in syntactic order, and could perhaps be limited to “partial application” style closures and single-argument closures. In other cases `_N` would be used rather than `$N`.</div><div><br class=""></div><div>-Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Joe</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 2, 2016, at 10:41 AM, Greg Titus 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What about $N? :-) </div><div class=""><br class=""></div><div class="">And then you could also put {} around it so that it is more obvious that partial1 is being assigned something that acts like a closure, and then you end up with:</div><div class=""><br class=""></div><div class="">let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) }<br class="">let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }<br class=""><div class=""><br class=""></div></div><div class="">instead of:</div><div class=""><blockquote type="cite" class="">let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: _) <br class="Apple-interchange-newline">let partial2 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: _, x: _) <br class="Apple-interchange-newline"></blockquote><div class=""><br class=""></div><div class="">I’m -1.</div></div><div class=""><br class=""></div><div class="">With the way that single expression closures work, and the fact that they are so syntactically light, I don’t think that this proposal would add utility, it would just be one more construct to learn.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Greg</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 2, 2016, at 10:28 AM, Gwendal Roué 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">What about nothing?<div class=""><br class=""></div><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><pre class="" style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal;"><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> partial1 <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> f(arg1: 1, arg2:)</pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="">Gwendal</div><div class=""><br class=""><blockquote type="cite" class="">Le 2 févr. 2016 à 19:26, Gwendal Roué <<a href="mailto:gwendal.roue@gmail.com" class="">gwendal.roue@gmail.com</a>> a écrit :<br class=""><br class="">Any operator character would be bad, since the function may accept it, as in `[1,2,3].reduce(1, combine: *)`<br class=""><br class="">Gwendal<br class=""><br class=""><blockquote type="cite" class="">Le 2 févr. 2016 à 19:24, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Feb 2, 2016, at 11:20 AM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:<br class=""><br class="">On Feb 2, 2016, at 10:16 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">One superficial comment on this: the use of _ here is a bad idea. _ already means something in expressions - “discard”, and a closely related thing in declarations - “ignore”. <br class=""><br class="">Adding a third very different thing (placeholder to be filled in later) seems like a really confusing thing to do.<br class=""><br class="">-Chris<br class=""><br class=""></blockquote><br class=""><br class="">#?<br class=""></blockquote><br class=""># means “macro like” or “compiler synthesized”.<br class=""><br class="">-Chris<br class=""><br class=""></blockquote><br class="">* would be bad, right? And naked ?-marks?<br class=""><br class="">-- E<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""></blockquote><br class=""></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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=""></body></html>