<div dir="ltr">Now that escaping with \ has been proposed for KeyPaths, this makes me wonder whether it would be appropriate to use "\foo()" rather than "foo(_)"/"foo(:)" ? It still feels a bit strange, as \foo() looks like escaping the <b>result</b> of a call.<div><br></div><div><div class="gmail_extra">
<br><div class="gmail_quote">On Sat, Feb 25, 2017 at 1:43 PM, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4474339546849733160Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>I don't have a <i>good</i> answer for this, but I'll vote <i>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><br></div><div>(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></div></blockquote><div><br></div></span><div>It is potentially going to be hard to fight that battle. I think a lot of functional/Haskell people love them and would be sad to see them go away (I plead guilty). But it isn’t a well known part of the language so I don’t think the general community would miss it.</div><br><blockquote type="cite"><div><span class=""><div style="word-wrap:break-word"><div>Jordan</div><div><br></div><br><div><blockquote type="cite"><div>On Feb 21, 2017, at 23:05, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@gmail.com</a>> wrote:</div><br class="m_-4474339546849733160Apple-interchange-newline"><div><div dir="ltr"><div>Evolutioniers,</div><div><br></div><div><b>Compound name syntax</b> — <font face="monospace, monospace">foo(_:)</font>, <font face="monospace, monospace">foo(bar:)</font>, <font face="monospace, monospace">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><br></div><div><div><font face="monospace, monospace"> func foo() {} // no compound syntax for this one :(</font></div><div><font face="monospace, monospace"> func foo(_ bar: Int) {} // foo(_:)</font></div><div><font face="monospace, monospace"> func foo(bar: Int) {} // foo(bar:)</font></div><div><font face="monospace, monospace"> func foo(bar: String, baz: Double) {} // foo(bar:baz:)</font></div></div><div><br></div><div>Given these four functions, only the first one has no compound name syntax. And the simple reference "<font face="monospace, monospace">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">let myfn = foo as () -> Void</font>".</div><div><br></div><div>I filed <a href="https://bugs.swift.org/browse/SR-3550" target="_blank">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><br></div><div>To kick off the discussion, <b>I'd like to propose <font face="monospace, monospace">foo(:)</font> for nullary functions.</b></div><div><br></div><div>Advantages:</div><div>- the colon marks a clear similarity to the <font face="monospace, monospace">foo(bar:)</font> form when argument labels are present.</div><div>- cutely parallels the empty dictionary literal, <font face="monospace, monospace">[:]</font>.</div><div><br></div><div>Disadvantages:</div><div>- violates intuition about one-colon-per-argument.</div><div>- the parallel between <font face="monospace, monospace">#selector(foo(:))</font> and <font face="monospace, monospace">@selector(foo)</font> is not quite as obvious as between <font face="monospace, monospace">#selector(foo(_:))</font> and <font face="monospace, monospace">@selector(foo:)</font>.</div><div><br></div><div><br></div><div>For the sake of discussion, another option would be <font face="monospace, monospace"><b>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><br></div><div><div><br></div><div>Looking forward to everyone's bikeshed color ideas,<br clear="all"><div><div class="m_-4474339546849733160gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
</div></div></div>
</div></blockquote></div><br></div></span><span class="">______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div></div></div>