<div dir="ltr"><div>Reasonable. That all makes sense.</div><div><br></div><div>For clarity&#39;s sake, there&#39;s really two syntactic issues that I think would be good to address. The first, which I think is the far bigger problem, which is that right now a list of params with closures is very hard to read. For example, this requires mental effort to decode whether this is returning an Int, or a closure returning an Int:<div><br></div><div><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><font face="monospace, monospace"><span style="white-space:normal">func makeIncrementer(forIncrement amount: Int) -&gt; () -&gt; Int {</span></font></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px">}</pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">And the second being that stylistically, having the params on the inside of the closure is breaking precedent of params outside of the block of code without gaining much. </span><br></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">Perhaps we could adopt the Obj-C ^ as a closure indicator. I think with existing Swift syntax, a lot of the confusion that caused <a href="http://www.fuckingblocksyntax.com">www.fuckingblocksyntax.com</a> would be avoided.</span><br></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">=== Local variable / property ===:</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">var closure = ^(Int) -&gt; Bool</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">or</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">var closure = ^(number: Int) -&gt; Bool {</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">    if (number == 3) { return true }</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">}</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">=== Method param ===</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">func </span><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">makeIncrementer(forIncrement amount: Int) -&gt; ^() -&gt; Int {</span></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">or </span></pre><pre style=""><pre style="color:rgb(80,0,80);font-size:12.8px;white-space:pre-wrap"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">func </span><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">makeIncrementer(forIncrement amount: Int) -&gt; ^(() -&gt; Int) {</span></pre><pre style="color:rgb(80,0,80);font-size:12.8px;white-space:pre-wrap"><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">=== Argument ===</span></pre><pre style="color:rgb(80,0,80);font-size:12.8px;white-space:pre-wrap"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;white-space:normal">func </span><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">makeIncrementer(forIncrement amount: ^((Int) -&gt; Bool)) -&gt; Bool {}</span></pre><pre style="color:rgb(80,0,80);font-size:12.8px;white-space:pre-wrap"><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">makeIncrementer(forIncrement: ^(number: Int) {</span></pre><pre style="color:rgb(80,0,80);font-size:12.8px;white-space:pre-wrap"><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">   if (number == 3) { return true }</span></pre><pre style="color:rgb(80,0,80);font-size:12.8px;white-space:pre-wrap"><span style="white-space:normal;font-family:monospace,monospace;font-size:12.8px">})</span></pre><pre style="color:rgb(80,0,80);font-size:12.8px"><font face="monospace, monospace"><span style="white-space:normal">=== typealias ===</span></font></pre><pre style=""><font color="#500050" face="monospace, monospace"><span style="font-size:12.8px;white-space:normal">typealias CustomType = ^(String) -&gt; Bool</span></font><font color="#500050"><span style="font-size:12.8px"><br></span></font></pre><pre style="">=== Takes no params, returns void (We take for granted if there&#39;s no return, it&#39;s void) ===</pre><pre style="">^()</pre><pre style=""><br></pre><pre style="">And I think we can use all the shorthands we currently use:</pre><pre style=""><br></pre><pre style="">=== Calling no params, takes void === </pre><pre style="">functionWithVoidCallback {</pre><pre style="">   //Do a thing</pre><pre style="">}</pre><pre style=""><br></pre><pre style="">=== Using $0 $1 syntax ===</pre><pre style="">func compare(_ comparator: ^(a: Int, b: Int) -&gt; Bool) { }</pre><pre style="">compare {</pre><pre style="">  %0 &gt; %1</pre><pre style="">}</pre></pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px">By having ^ mark an upcoming closure, I think it&#39;s a lot easier to follow what&#39;s going on with declarations because as you read left to right, you&#39;re prepped that a closure syntax is coming up as you read left to right. It also allows you to keep the params outside of the closure, which I think is a win. Closure params would also have the same syntax everywhere, and be extremely similar to normal method calls which would be easier for new Swift users. </pre><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px">-E</pre><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 29, 2015 at 10:13 PM, David Waite <span dir="ltr">&lt;<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Dec 29, 2015, at 5:18 PM, Ethan Diamond via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-size:12.8px">I guess the core of the question for me is why have the concept of a closure at all when they&#39;re harder to read while acting the same way that functions do? I&#39;m not a huge fan of Javascript, but the consistancy between function declarations and anonymous functions is something I feel they got right. JS syntax for everything that receives parameters and possibly returns a value is entirely consistent. </div></div></div></blockquote><div><br></div></span>Some of this is because Javascript doesn&#39;t have to declare types or return values and it is even loose with arguments and is somewhat confusing (and dynamic) with “this”. For Swift, which requires knowledge about the arguments and return values needed by callers, it makes sense to have two different syntaxes depending on whether or not this knowledge is being defined by contract or being inferred by context.</div><div><br></div><div>And with ES2015 there are now multiple styles, partially to resolve the issues with capturing “this” and partially because writing “function” everywhere is visually distracting.</div><div><span><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-size:12.8px"><span style="font-size:12.8px">Let&#39;s take the anonymous function style:</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><font face="monospace, monospace">func asyncWithCallback(_ : func (String) -&gt; Bool)</font></div><div style="font-size:12.8px"><font face="monospace, monospace"><br></font></div><div style="font-size:12.8px"><font face="monospace, monospace">asyncWithCallback(func (param) {</font></div><div style="font-size:12.8px"><font face="monospace, monospace">    return param == &quot;string&quot;</font></div><div style="font-size:12.8px"><font face="monospace, monospace">})</font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Particularly for someone new to the language is both clearer and shorter than this, which makes the caller rewrite the return type in the closure:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><font face="monospace, monospace">func asyncWithCallback(_ : String -&gt; Bool)</font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><font face="monospace, monospace">asyncWithCallback {</font></div><div style="font-size:12.8px"><font face="monospace, monospace">  (param: String) -&gt; Bool in</font></div><div style="font-size:12.8px"><font face="monospace, monospace">  return param == &quot;string&quot;</font></div><div style="font-size:12.8px"><font face="monospace, monospace">}</font></div></div></blockquote><div><br></div></span>Or I could use:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="margin:0px;line-height:normal;font-family:Menlo;color:rgb(41,76,80)">asyncWithCallback<span style="color:rgb(0,0,0)"> {</span></div></div><div><div style="margin:0px;line-height:normal;font-family:Menlo">    param <span style="color:rgb(195,34,117)">in</span></div></div><div><div style="margin:0px;line-height:normal;font-family:Menlo">    <span style="color:rgb(195,34,117)">return</span> param == <span style="color:rgb(201,27,19)">&quot;string&quot;</span></div></div><div><div style="margin:0px;line-height:normal;font-family:Menlo">}</div></div></blockquote><div><div style="margin:0px;line-height:normal;font-family:Menlo;min-height:21px"><br></div><div style="margin:0px;line-height:normal;font-family:Menlo;min-height:21px">or even:</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div style="margin:0px;line-height:normal"><font color="#294c50" face="Menlo">asyncWithCallback</font><span style="color:rgb(0,0,0);font-family:Menlo"> { $0 == </span><span style="color:rgb(201,27,19);font-family:Menlo">&quot;string</span><font color="#c91b13" face="Menlo">”</font><font face="Menlo"> }</font></div></div></blockquote><font face="Menlo"><div><br></div><div>A function defines a name and a contract for use and definition, while closures are only semantically valid once defined by a context. I can understand the stylistic desire to have closures declare arguments outside a block and to be closer to function syntax. However, using “func&quot; anonymously to indicate a different syntax with a different set of options, potentially inferred input types, and an inferred existence of output as well as output type might be equally confusing. Perhaps another keyword could be used for this purpose. </div><div><br></div><div>However this new keyword would need to work with, and avoid adding visual distraction to, the “$0 == “string” case above.</div></font><div><font face="Menlo"><br></font><div><span><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">It still fits your unwritten rule to be able to compose language features in Swift, assuming you leave the same syntactic sugar: <br></div><div style="font-size:12.8px"><pre style="white-space:pre-wrap">func if (_ control: Bool, _ path: func ()) {</pre><pre style="white-space:pre-wrap">  if (control) {</pre><pre style="white-space:pre-wrap">     path()</pre><pre style="white-space:pre-wrap">  }</pre><pre style="white-space:pre-wrap">}</pre><pre style="white-space:pre-wrap">if (a == b) {</pre><pre style="white-space:pre-wrap">  //LETS DO SOME STUFF</pre><pre style="white-space:pre-wrap">}</pre></div></div></div></blockquote></span>You probably realize this but closures and blocks have different control flow, so for instance the above would absorb/malfunction on returns as well as attempts to break/continue outer loops.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div><div>-DW</div><br></font></span></div></div></blockquote></div><br></div></div></div></div>