<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 22 Feb 2017, at 10:24, Patrick Pijnappel 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 dir="ltr" class=""><div class="">I'd like to discuss allowing a trailing 'argument label' without an actual argument:</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">func adding(_ other: Self, reportingOverflow) -> … // Actual case in SE-104 where this came up</font><br class=""></div><div class=""><font face="monospace, monospace" class="">func tableView(_ tableView: UITableView, numberOfSections) -> Int // Referenced as tableView(_:numberOfSections)</font></div><div class=""><br class=""></div><div class="">As illustrated above, the way we reference functions extends very naturally to include these.<br class=""></div><div class=""><br class=""></div><div class="">This would be very useful for several cases:</div><div class="">• Delegate methods, which currently all start with the same prefix, except for some odd cases that really actually just needed a trailing argument label.</div><div class="">• Cases where the function is a more specialized version of one with the same name, but can't use a flag because the return type is different (e.g. reportingOverflow), or the extra flag check is just undesirable. The standard library now uses some workarounds to achieve this (e.g. having a trailing argument of type void).</div><div class="">• Function names that just work more naturally with some additional words after the last argument. If we allow trailing argument labels, you can form any sentence, rounding out the syntax. </div><div class=""><br class=""></div><div class="">Overall, I think this could be the final missing piece to complete Swift's functions-as-sentences approach.</div></div></div></blockquote></div><br class=""><div class="">I'm a +1 for this.</div><div class=""><br class=""></div><div class="">I think the best way to define it though would be to use Void arguments, and simply eliminate the need to add :() to call them if they are trailing. We should however retain the ability to add the colon for disambiguation.</div><div class=""><br class=""></div><div class="">Some examples to illustrate:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Foo { func adding(_ other:Foo, reportingOverflow:Void) { … } }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var a = Foo(), b = Foo()</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.adding(b, reportingOverflow) // Trailing Void argument doesn't require a value, so :() can be omitted</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let reportingOverflow = "I don't know why I defined this"</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.adding(b, reportingOverflow) // This is now ambiguous thanks to my stupidly named variable</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a.adding(b, reportingOverflow:) // However, this isn't, thanks to the colon clarifying that it's a label</font></div><div class=""><br class=""></div><div class="">It's possible the feature doesn't have to be restricted to only trailing arguments; the key is the ambiguity due to variable names and/or function selection. For example:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Foo { func example(foo:Void) -> String { … }}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var foo = Foo()</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo.example(foo) // What did I mean here?</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let result = foo.example(foo:) // This looks like I might be trying to select a function, rather than call it</font></div><div class=""><br class=""></div><div class="">So it's possible it could be allowed for any function that has at least one non-Void argument?</div><div class=""><br class=""></div><div class="">I think to really seal the deal it would be nice if Xcode would highlight argument labels differently, as that would make it clearer to user's what something is at a glance, but that's a separate issue.</div><div class=""><br class=""></div><div class="">Just some thoughts; I do prefer this to using single case enums just to create a different method signature. Labels are definitely the right way to do this. The main thing for me is that I think we should keep the requirement to specify the type in the function declaration as Void, just for clarity.</div></body></html>