<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 21:25, Patrick Pijnappel <<a href="mailto:patrickpijnappel@gmail.com" class="">patrickpijnappel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">To summarize, there's one ambiguous case we'd need to resolve:<div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">func foo(_ x: Int, reportingOverflow)</font></div><div class=""><span style="font-family:monospace,monospace" class="">func foo(_ x: Int, _ reportingOverflow: Bool)</span></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">let reportingOverflow = true</span></div><div class=""><span style="font-family:monospace,monospace" class="">foo(5, reportingOverflow) // Ambiguous</span></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class=""><font face="arial, helvetica, sans-serif" class="">One solution is to make trailing argument labels syntactic sugar for a trailing void argument.</font></div><div class=""><font face="arial, helvetica, sans-serif" class="">That would allow breaking ambiguity by specifying it explicitly:</font></div><div class=""><font face="arial, helvetica, sans-serif" class=""><br class=""></font></div><div class=""><span style="font-family:monospace,monospace" class="">foo(5, reportingOverflow: ())</span><br class=""></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class=""><font face="arial, helvetica, sans-serif" class="">A related issue is the call-site ambiguity for the reader (less of a problem if Xcode highlighted argument labels).</font></div></div></div></blockquote></div><br class=""><div class="">Vladimir suggested that an alternative might be to use a leading colon to indicate that the label is for selecting a function only, which would solve the ambiguity issues. Of course this means it's much the same as using the single enum case trick, but at least this way it'd still be a proper language feature rather than a workaround, and no extra types are declared just to support it.</div><div class=""><br class=""></div><div class="">So you'd have something like:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(_ x:Int, :reportingOverflow) { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(_ x:Int, _ reportingOverflow:Bool) { … }</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 = true</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo(5, reportingOverflow) // Calls the second declaration of foo using the boolean argument</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo(5, :reportingOverflow) // Calls the first declaration of foo</font></div><div class=""><br class=""></div><div class="">It's still a little subtle, but the single-case enum that this feature would replace has the exact same problem. So long as the label is sufficiently descriptive it shouldn't be a very likely target for a naming collision.</div><div class=""><br class=""></div><div class="">I think the leading colon alternative is probably the one I'd favour, as a plain argument label probably isn't clear enough, so having an indicator is better overall. It means that as a feature it won't have any advantages over the single-case enum, except that you don't have to declare an unnecessary extra type (which needs to be documented somehow), so I think it's still worth having to make this capability part of the function signature proper.</div></body></html>