<div dir="ltr">Incidentally--and I suppose I will have to repeat myself somewhere else in the likely case that this is not seen by the people who are designing this feature--using the sigil syntax `\foo()` nicely solves the nullary function problem, but we get another ambiguity with the introduction of key paths and function references using the same syntax:<div><br></div><div>Currently, it is possible to have a member `var foo` and another `func foo(bar:baz:)` in the same type. There is no real necessity to forbid that, though I doubt it would break too many people&#39;s code. (I did, however, once suggest naming `FloatingPoint.ulpOfOne` to simply `FloatingPoint.ulp`, which would have taken advantage of this rule.)</div><div><br></div><div>In such a scenario, `\foo` becomes ambiguous. It would be sufficient to say that in such scenarios `\foo` is always interpreted as referring to `var foo`, while `\foo(bar:baz:)` becomes the only way of writing a reference to the function.</div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 6, 2017 at 9:59 AM, Ricardo Parada <span dir="ltr">&lt;<a href="mailto:rparada@mac.com" target="_blank">rparada@mac.com</a>&gt;</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">Agree.<div><div class="h5"><div><br></div><div><br><div><blockquote type="cite"><div>On Apr 6, 2017, at 8:02 AM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_672652077236712861Apple-interchange-newline"><div><div>Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously distinguished from foo(), I think that would be the only logical result.</div><div><br></div><div><br><div class="gmail_quote"><div>On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_672652077236712861gmail_msg">Now that escaping with \ has been proposed for KeyPaths, this makes me wonder whether it would be appropriate to use &quot;\foo()&quot; rather than &quot;foo(_)&quot;/&quot;foo(:)&quot; ?  It still feels a bit strange, as \foo() looks like escaping the <b class="m_672652077236712861gmail_msg">result</b> of a call.</div><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg"><div class="gmail_extra m_672652077236712861gmail_msg">
<br class="m_672652077236712861gmail_msg"><div class="gmail_quote m_672652077236712861gmail_msg">On Sat, Feb 25, 2017 at 1:43 PM, David Hart <span class="m_672652077236712861gmail_msg">&lt;<a href="mailto:david@hartbit.com" class="m_672652077236712861gmail_msg" target="_blank">david@hartbit.com</a>&gt;</span> wrote:<br class="m_672652077236712861gmail_msg"><blockquote class="gmail_quote m_672652077236712861gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><span class="m_672652077236712861gmail_msg"><blockquote type="cite" class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg">On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="m_672652077236712861gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_672652077236712861m_-847555223454010977m_-4474339546849733160Apple-interchange-newline m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><div style="word-wrap:break-word" class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg">I don&#39;t have a <i class="m_672652077236712861gmail_msg">good</i> answer for this, but I&#39;ll vote <i class="m_672652077236712861gmail_msg">against</i> &#39;foo(:)&#39; because that&#39;s what a lot of people think the name of &#39;foo(_:)&#39; should be. I&#39;d rather be able to offer fix-its for that even when you have both &#39;foo()&#39; and &#39;foo(_:)&#39; defined. I&#39;d rather go with &#39;foo(_)&#39; despite the tiny ambiguity in pattern contexts.</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">(I&#39;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&#39;d only need this for #selector, and it&#39;s perfectly unambiguous to use &#39;foo()&#39; there. But I wasn&#39;t planning to fight that particular battle now, and it is rather annoying to require the &#39;as&#39; in the meantime.)</div></div></div></blockquote><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div></span><div class="m_672652077236712861gmail_msg">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 class="m_672652077236712861gmail_msg"><blockquote type="cite" class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><span class="m_672652077236712861gmail_msg"><div style="word-wrap:break-word" class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg">Jordan</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><br class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><blockquote type="cite" class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg">On Feb 21, 2017, at 23:05, Jacob Bandes-Storch &lt;<a href="mailto:jtbandes@gmail.com" class="m_672652077236712861gmail_msg" target="_blank">jtbandes@gmail.com</a>&gt; wrote:</div><br class="m_672652077236712861m_-847555223454010977m_-4474339546849733160Apple-interchange-newline m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg">Evolutioniers,</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg"><b class="m_672652077236712861gmail_msg">Compound name syntax</b> — <font face="monospace, monospace" class="m_672652077236712861gmail_msg">foo(_:)</font>, <font face="monospace, monospace" class="m_672652077236712861gmail_msg">foo(bar:)</font>, <font face="monospace, monospace" class="m_672652077236712861gmail_msg">foo(bar:baz:)</font> — is used to disambiguate references to functions. (You might&#39;ve used it inside a #selector expression.) But there&#39;s currently no compound name for a function with no arguments.</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><font face="monospace, monospace" class="m_672652077236712861gmail_msg">    func foo() {}  // no compound syntax for this one :(</font></div><div class="m_672652077236712861gmail_msg"><font face="monospace, monospace" class="m_672652077236712861gmail_msg">    func foo(_ bar: Int) {}  // foo(_:)</font></div><div class="m_672652077236712861gmail_msg"><font face="monospace, monospace" class="m_672652077236712861gmail_msg">    func foo(bar: Int) {}  // foo(bar:)</font></div><div class="m_672652077236712861gmail_msg"><font face="monospace, monospace" class="m_672652077236712861gmail_msg">    func foo(bar: String, baz: Double) {}  // foo(bar:baz:)</font></div></div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">Given these four functions, only the first one has no compound name syntax. And the simple reference &quot;<font face="monospace, monospace" class="m_672652077236712861gmail_msg">let myfn = foo</font>&quot; is ambiguous because it could refer to any of the four. A workaround is to specify a contextual type, e.g. &quot;<font face="monospace, monospace" class="m_672652077236712861gmail_msg">let myfn = foo as () -&gt; Void</font>&quot;.</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">I filed <a href="https://bugs.swift.org/browse/SR-3550" class="m_672652077236712861gmail_msg" target="_blank">SR-3550</a> for this a while ago, and there was some discussion in JIRA about it. I&#39;d like to continue exploring solutions here and then write up a formal proposal.</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">To kick off the discussion, <b class="m_672652077236712861gmail_msg">I&#39;d like to propose <font face="monospace, monospace" class="m_672652077236712861gmail_msg">foo(:)</font> for nullary functions.</b></div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">Advantages:</div><div class="m_672652077236712861gmail_msg">- the colon marks a clear similarity to the <font face="monospace, monospace" class="m_672652077236712861gmail_msg">foo(bar:)</font> form when argument labels are present.</div><div class="m_672652077236712861gmail_msg">- cutely parallels the empty dictionary literal, <font face="monospace, monospace" class="m_672652077236712861gmail_msg">[:]</font>.</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">Disadvantages:</div><div class="m_672652077236712861gmail_msg">- violates intuition about one-colon-per-argument.</div><div class="m_672652077236712861gmail_msg">- the parallel between <font face="monospace, monospace" class="m_672652077236712861gmail_msg">#selector(foo(:))</font> and <font face="monospace, monospace" class="m_672652077236712861gmail_msg">@selector(foo)</font> is not quite as obvious as between <font face="monospace, monospace" class="m_672652077236712861gmail_msg">#selector(foo(_:))</font> and <font face="monospace, monospace" class="m_672652077236712861gmail_msg">@selector(foo:)</font>.</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">For the sake of discussion, another option would be <font face="monospace, monospace" class="m_672652077236712861gmail_msg"><b class="m_672652077236712861gmail_msg">foo(_)</b></font>. This was my original choice, and I like that the number of colons matches the number of parameters. However, it&#39;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&#39;t be compared with ~= anyway).</div><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><br class="m_672652077236712861gmail_msg"></div><div class="m_672652077236712861gmail_msg">Looking forward to everyone&#39;s bikeshed color ideas,<br clear="all" class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg m_672652077236712861m_-847555223454010977m_-4474339546849733160gmail_signature"><div class="m_672652077236712861gmail_msg"><div class="m_672652077236712861gmail_msg">Jacob<br class="m_672652077236712861gmail_msg"></div></div></div></div>
</div></div></div>
</div></blockquote></div><br class="m_672652077236712861gmail_msg"></div></span><span class="m_672652077236712861gmail_msg">______________________________<wbr>_________________<br class="m_672652077236712861gmail_msg">swift-evolution mailing list<br class="m_672652077236712861gmail_msg"><a href="mailto:swift-evolution@swift.org" class="m_672652077236712861gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_672652077236712861gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="m_672652077236712861gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_672652077236712861gmail_msg"></span></div></blockquote></div><br class="m_672652077236712861gmail_msg"></div></blockquote></div><br class="m_672652077236712861gmail_msg"></div></div></div>
______________________________<wbr>_________________<br class="m_672652077236712861gmail_msg">
swift-evolution mailing list<br class="m_672652077236712861gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_672652077236712861gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_672652077236712861gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_672652077236712861gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_672652077236712861gmail_msg">
</blockquote></div></div>
______________________________<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></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div></div></div>