<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="" applecontenteditable="true"><div class="">Whoops, after hitting Send I realized that I don't want to kill references to <i class="">non-member </i>functions, which means it's still useful to have a syntax for this. Still, there is one simple and unambiguous spelling when you need it…</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">{ foo() }</div></blockquote><div class=""><br class=""></div><div class="">trollface.gif,</div><div class="">Jordan</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Feb 24, 2017, at 15:56, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</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="" applecontenteditable="true"><div class="">I don't have a <i class="">good</i> answer for this, but I'll vote <i class="">against</i> 'foo(:)' because that's what a lot of people think the name of 'foo(_:)' should be. I'd rather be able to offer fix-its for that even when you have both 'foo()' and 'foo(_:)' defined. I'd rather go with 'foo(_)' despite the tiny ambiguity in pattern contexts.</div><div class=""><br class=""></div><div class="">(I'm personally in favor of killing unapplied function references altogether in favor of closures, on the grounds that they are overly terse, make type-checking more complicated, and often lead to retain cycles. Then we'd only need this for #selector, and it's perfectly unambiguous to use 'foo()' there. But I wasn't planning to fight that particular battle now, and it is rather annoying to require the 'as' in the meantime.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 23:05, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Evolutioniers,</div><div class=""><br class=""></div><div class=""><b class="">Compound name syntax</b> — <font face="monospace, monospace" class="">foo(_:)</font>, <font face="monospace, monospace" class="">foo(bar:)</font>, <font face="monospace, monospace" class="">foo(bar:baz:)</font> — is used to disambiguate references to functions. (You might've used it inside a #selector expression.) But there's currently no compound name for a function with no arguments.</div><div class=""><br class=""></div><div class=""><div class=""><font face="monospace, monospace" class=""> func foo() {} // no compound syntax for this one :(</font></div><div class=""><font face="monospace, monospace" class=""> func foo(_ bar: Int) {} // foo(_:)</font></div><div class=""><font face="monospace, monospace" class=""> func foo(bar: Int) {} // foo(bar:)</font></div><div class=""><font face="monospace, monospace" class=""> func foo(bar: String, baz: Double) {} // foo(bar:baz:)</font></div></div><div class=""><br class=""></div><div class="">Given these four functions, only the first one has no compound name syntax. And the simple reference "<font face="monospace, monospace" class="">let myfn = foo</font>" is ambiguous because it could refer to any of the four. A workaround is to specify a contextual type, e.g. "<font face="monospace, monospace" class="">let myfn = foo as () -> Void</font>".</div><div class=""><br class=""></div><div class="">I filed <a href="https://bugs.swift.org/browse/SR-3550" class="">SR-3550</a> for this a while ago, and there was some discussion in JIRA about it. I'd like to continue exploring solutions here and then write up a formal proposal.</div><div class=""><br class=""></div><div class="">To kick off the discussion, <b class="">I'd like to propose <font face="monospace, monospace" class="">foo(:)</font> for nullary functions.</b></div><div class=""><br class=""></div><div class="">Advantages:</div><div class="">- the colon marks a clear similarity to the <font face="monospace, monospace" class="">foo(bar:)</font> form when argument labels are present.</div><div class="">- cutely parallels the empty dictionary literal, <font face="monospace, monospace" class="">[:]</font>.</div><div class=""><br class=""></div><div class="">Disadvantages:</div><div class="">- violates intuition about one-colon-per-argument.</div><div class="">- the parallel between <font face="monospace, monospace" class="">#selector(foo(:))</font> and <font face="monospace, monospace" class="">@selector(foo)</font> is not quite as obvious as between <font face="monospace, monospace" class="">#selector(foo(_:))</font> and <font face="monospace, monospace" class="">@selector(foo:)</font>.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">For the sake of discussion, another option would be <font face="monospace, monospace" class=""><b class="">foo(_)</b></font>. This was my original choice, and I like that the number of colons matches the number of parameters. However, it's a little less obvious as a function reference. It would preclude _ from acting as an actual identifier, and might conflict with pattern-matching syntax (although it appears functions can't be compared with ~= anyway).</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">Looking forward to everyone's bikeshed color ideas,<br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
</div></div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>