<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 Aug 18, 2016, at 11:17 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Sorry for mentioning this issue again, as it seems to have been already much discussed, but i've had the unfortunate experience of dealing with the consequences of this proposal in my code since xcode beta 6, which i really can't get my head around. <div class=""><br class=""></div><div class="">Could someone explain what is the rational behind the choice of having parameter names prohibited for closures but compulsory for functions ?</div><div class=""><br class=""></div><div class="">As a software developper (and not a language expert), I would have hoped to get functions behave as close to closures as possible.</div><div class=""><br class=""></div><div class="">aka : </div><div class=""><br class=""></div><div class="">func myAdd(a : Int, b: Int) -> Int</div><div class="">myAdd(a: 1 , b :2 ) -- OK</div><div class=""><br class=""></div><div class="">vs</div><div class=""><br class=""></div><div class="">let myAdd = (_ a: Int, _ b: Int) -> Int</div><div class="">myAdd (a:1, b: 2) -- not ok still ?</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is a topic for swift-evolution; adding swift-evolution, and BCC’ing swift-dev.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">After having read the argument that "parameter names are part of the function names, and not its type", i'm convinced that the whole proposal makes sense. However i can't get my head around that specific line of the proposal : </div><div class="">"If the invocation refers to a value, property, or variable of function type, the argument labels do not need to be supplied. <u class="">It will be an error to supply argument labels in this situation</u>."<br class=""></div><div class=""><br class=""></div><div class="">Why make it an error in case of closures ? </div></div></div></blockquote><div class=""><br class=""></div><div class="">A closure is an expression that creates an anonymous function, hence there is no place to put the argument labels.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> If we agree that parameter are part of the name, then it should behave just like a name. Specifying names shouldn't matter more than the name of the variable storing the closure. It seems to me, humbly, that the fact that part of the name is split and written closer to the parameters could be considered just as syntactic sugar. </div></div></div></blockquote><div class=""><br class=""></div><div class="">We could invent a language extension there. The point of requiring the underscores in:</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>let myAdd: (_ a: Int, _ b: Int) -> Int</div><div class=""><br class=""></div><div class="">Is to allow for some future evolution here. IIRC, it was discussed in the review thread, that we could imagine ‘let’s with compound names, e.g.,</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>let myAdd(a:b:): (Int, Int) -> Int</div><div class=""><br class=""></div><div class="">Or perhaps allow syntactic sugar such as</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>let myAdd: (a: Int, b: Int) -> Int</div><div class=""><br class=""></div><div class="">To be the same thing. Again, this is future language extensions.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Another hint that something's wrong : the proposal still lets the possibility to specify names in type declarations for documentation purpose, using "_" . But then why not let us specify those names at call site too ? </div></div></div></blockquote><div class=""><br class=""></div><div class="">Because they are parameter names, not argument labels. If you declare a function with parameter names but not argument labels:</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>func f(_ a: Int) { }</div><div class=""><br class=""></div><div class="">You *cannot* specify argument labels at the call site:</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>f(a: 1) // error: first argument is unlabeled</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">callback( nil, nil, nil, request) isn't really pleasant to read compared to callback(data:nil, error:nil, info:nil, request: request) </div></div></div></blockquote><div class=""><br class=""></div><div class="">This was a known issue with the Swift 3 change, and there are (known) possible future language directions to bring back some of this. We focused on fixing the type system oddities first in Swift 3 (that’s the breaking part) and can consider improvements in the future.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Would the future directions given in SE-0111 be appropriate for consideration in the current phase of Swift 4 evolution, or would they be irrelevant to the ABI?</div></div></div></div></div></blockquote><br class=""></div><div>They don’t have ABI impact, so they’d be the in “stage 2” bucket for Swift 4.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>