<div dir="ltr"><div style="font-size:12.8px"><div style="font-size:12.8px"><i style="font-size:12.8px">There are three pieces at play here IMHO:</i><br></div><div style="font-size:12.8px"><i>1. How functions (global and on types) are declared and implemented</i></div><div style="font-size:12.8px"><i>2. How function specifications are indicated as types</i></div><div style="font-size:12.8px"><i>3. How anonymous functions are declared and implemented</i></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Agreed, so lets flush out the rules a little more and see if we can find a common language for all three, since they&#39;re interconnected. For the sake of clarity, I&#39;m going to refer to closures as blocks, since they&#39;re effectively the same thing. I think we should begin with these three rules:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1. Let&#39;s try to keep precedent for function calls, since blocks are pretty much functions</div><div style="font-size:12.8px">2. A ^ signifies that we are now entering a block context with regards to syntax</div><div style="font-size:12.8px">3. Just as in a lot of the rest of Swift, let&#39;s infer information we can, but optionally allow it to be respecified if it makes the syntax clearer</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">From there, I think the solution to your #2 (<i style="font-size:12.8px">How function specifications are indicated as types) </i><span style="font-size:12.8px">naturally presents itself. This is a normal function declaration:</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><font face="monospace, monospace">func funcName(param) -&gt; return_type</font></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">A block is effectively a function without a name - an anonymous function. So we remove the name. I also agree with your earlier points that func is inappropriate terminology for what we&#39;re trying to do so we remove that too. Using the ^ rule to signify a block, we get these options, which I think should both be valid:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><font face="monospace, monospace">^(param) -&gt; return_type</font></div><div style="font-size:12.8px"><font face="monospace, monospace">^((param) -&gt; return_type)</font></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Which I find to be easier to read than the current closure type:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="monospace, monospace">(param) -&gt; return_type</font></div><div class="gmail_extra"><br></div><div class="gmail_extra">because it shares syntax with tuples up until the -&gt;, the () are optional making the param share syntax with whatever type the param is, and because when nested closure type syntax become particularly nasty to read.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Indeed, I think it gives us the opportunity for one more gain here. We have functions with named parameters because of Swift&#39;s goal of clarity. This gives us the opportunity for blocks to also have named parameters. Which one of these is better?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="monospace, monospace">func fetchHTML(callback: (String, Int) -&gt; Error?)</font></div><div class="gmail_extra"><br></div><div class="gmail_extra">or </div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="monospace, monospace">func fetchHTML(callback: ^(url: String, allowedResponseCode: Int) -&gt; Error?)</font></div><div class="gmail_extra"><font face="monospace, monospace"><br></font></div><div class="gmail_extra">The named params aren&#39;t enforced when the block is defined, but provides hints for the Swift user who defines the block body. They can rename those params if they want, but it gives them a hint on how those params will be used, and will autocomplete when they go to write the body with those names.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">From there, I think we have the answer to your question #1 as well (<i style="font-size:12.8px">How functions are declared and implemented) </i><span style="font-size:12.8px">in that aside from using our new block type syntax for their params, they are completely unchanged. However, the new block type syntax makes function declarations easier to read.</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">As I listed before, we take this, which I find hard to read at a glance:</span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace"><br></font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace"><div class="gmail_extra">func makeIncrementer(forIncrement amount: Int) -&gt; () -&gt; Int { ... <span style="font-size:12.8px">}</span></div></font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra">and replace it with something better:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:monospace,monospace;font-size:12.8px">func makeIncrementer(forIncrement amount: Int) -&gt; ^() -&gt; Int { ... </span><span style="font-family:monospace,monospace;font-size:12.8px">}</span><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">or, what I feel should be an option with the ^ syntax:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-family:monospace,monospace;font-size:12.8px">func makeIncrementer(forIncrement amount: Int) -&gt; ^(() -&gt; Int) { ... </span><span style="font-family:monospace,monospace;font-size:12.8px">}</span><br></div><div class="gmail_extra"><span style="font-family:monospace,monospace;font-size:12.8px"><br></span></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">I don&#39;t think you can look at that and tell me it&#39;s not clearer to read.</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">Your point 3 (</span></font><i style="font-size:12.8px">How anonymous functions are declared and implemented) </i><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">is a bit trickier to explain, but I think the explanation arises naturally from the three rules.</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">Let&#39;s start with rule 1, and look at the way we already define an call a function:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">func isNumberFour(number: Int) -&gt; Bool { </font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">    return </font></span><span style="font-family:monospace,monospace;font-size:12.8px">number</span><span style="font-size:12.8px"><font face="monospace, monospace"> == 4</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">}</font></span></div><div class="gmail_extra"><span style="font-family:monospace,monospace;font-size:12.8px">isNumberFour</span><span style="font-family:monospace,monospace;font-size:12.8px">(4)</span><br></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">Because we already know the param type and the return type, we don&#39;t need to respecify that information when we call the function. Using the same logic we used to come up with the block type syntax - removing &quot;func&quot; and since it has no name, basically using ^ as a signifier - we&#39;re going to be able to reason out exactly what this would look like:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">^(number: Int) -&gt; Bool {</font></span></div><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">    </span><span style="font-size:12.8px">return </span><span style="font-size:12.8px">number</span><span style="font-size:12.8px"> == 4</span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">} </font></span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">Let&#39;s take the case where a function has a block as a parameter:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">func isNumberFour(calculateNumber: ^((Int) -&gt; Int)) -&gt; Bool</font></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">How do I call this? If we&#39;re not using rule 3, inferring what we can, we would write out this, which I think should be valid syntax if desired by Swift&#39;s users:</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">let isFour: Bool = isNumberFour(calculateNumber: ^(number: Int) -&gt; Int {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">    return number * 2</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">})</font></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">But there&#39;s no reason to be that verbose. We have the isNumberFour declaration. Much like we don&#39;t need to specify that isFour is a Bool, Swift should also allow this:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">let isFour = isNumberFour(calculateNumber: ^(number) {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">   return number * 2</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">})</font></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">The compiler already knows enough about the block for that to work. We named the Int param for the calculateNumber block, so autocomplete can finish this for us. However, I also think it should be valid to be able to change the name when the block&#39;s body is defined. So this would also be valid:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">let isFour = isNumberFour(calculateNumber: ^(amount) {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">   return amount * 2</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">})</font></span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">So the rules we follow are pretty simple. When the block&#39;s body is defined, we only require users to specify the data the compiler can&#39;t infer, while having the option to specify the rest. I believe this is exactly what we&#39;re doing already with closures, we&#39;re just moving the part preceding the &quot;in&quot; to the outside of the method and prefixing it with a ^. It makes closures easier to reason about the syntax, and easier to read. </span></font></div></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">There are a few shorthands that would go with it. </span><span style="font-family:arial,helvetica,sans-serif;font-size:12.8px">Let&#39;s take the var / property case. Without using rule 3, removing syntax we can infer, we get this:</span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace"><br></font></span></div><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">var isNumberFour: ^(number: Int) -&gt; Bool = </span><span style="font-size:12.8px">^(number: Int) -&gt; Bool </span><span style="font-size:12.8px">{</span></font></div><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">    </span><span style="font-size:12.8px">return </span><span style="font-size:12.8px">number</span><span style="font-size:12.8px"> == 4</span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">}</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">isNumberFour(4)</font></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">But we already know the parameters, return type, and name of the parameters. So following rule 3, we can reduce this to:</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">var isNumberFour: ^(Int) -&gt; Bool = ^(</span></font><span style="font-family:monospace,monospace;font-size:12.8px">number) </span><span style="font-size:12.8px;font-family:monospace,monospace">{</span></div><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">    </span><span style="font-size:12.8px">return </span><span style="font-size:12.8px">number</span><span style="font-size:12.8px"> == 4</span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">}</font></span></div></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">But I would propose we allow this shorthand, since it&#39;s nicer to read:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">var isNumberFour: ^(number: Int) -&gt; Bool = </span></font><span style="font-size:12.8px;font-family:monospace,monospace">{</span></div><div class="gmail_extra"><font face="monospace, monospace"><span style="font-size:12.8px">    </span><span style="font-size:12.8px">return </span><span style="font-size:12.8px">number</span><span style="font-size:12.8px"> == 4</span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">}</font></span></div></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">As previously said, if there&#39;s no return type specified, we assume void. Also, if there&#39;s no params and returns void, you can bypass the ^() all together. So:</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">func async(_ callback: ^())</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace"><br></font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">async(^() {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">  //Do the callback</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">})</font></span></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">could still be written as:</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">async {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">  //Do the callback</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">}</font></span></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="font-size:12.8px">Much like closures in current Swift, if we want to use the $0 $1 shorthand, we can also skip the block param piece:</span></font></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace"><br></font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">func sort(_ comparator:^((a: Int, b: Int) -&gt; Bool))</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace"><br></font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">sort(^(a, b) {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">  return a &gt; b</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">})</font></span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif">could be written as:</span></div><div class="gmail_extra"><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">sort {</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">  return $0 &gt; $1</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">}</font></span></div><div class="gmail_extra"><br></div><div class="gmail_extra">And to answer your question, &quot;<span style="font-size:12.8px">Would this syntax still support single expression implicit returns, e.g. current Swift,&quot; the answer is still yes:</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px"><font face="monospace, monospace">[1,2,3].map(^(number) {number == 3})</font></span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><div style="font-size:12.8px"><div style="margin:0px;font-size:11px"><span style="font-size:small">I feel like this syntax feels intuitive, gets rid of the weird &quot;in&quot; syntax, and is closer to the function syntax people are used to. It also makes reading block types easier, particularly when nested. I know there&#39;s a lot of closure momentum to overcome at this point, but I really the time it would take to change this would be worth it down the road.</span><br></div><div style="margin:0px;font-size:11px"><span style="font-size:small"><br></span></div><div style="margin:0px;font-size:11px"><span style="font-size:small">-E</span></div><div style="margin:0px;font-size:11px"><span style="font-size:small"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 30, 2015 at 6:48 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"><div><span><blockquote type="cite"><div><div dir="ltr"><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></div></div></div></div></blockquote></span>I look at currying like a right-associative operator (like the ternary operator, or assignments in languages like C). There is a function that takes no arguments and returns an int, that you get from a function that takes an int argument.</div><div><br></div><div>Changing this to say</div><div><blockquote type="cite"><div dir="ltr"><div><div><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><font face="monospace, monospace">func makeIncrementer(forIncrement amount: Int) -&gt; func () -&gt; Int {</font></pre></div></div></div></blockquote><div>feels like it is changing the behavior to that of a non-associative operator. </div><div><br></div><div>One interesting result would be if by removing the ternary operator as it stands today and changing how currying heppens, swift wound up having no right associative operators left in core.</div><span><div><blockquote type="cite"><div dir="ltr"><div><div></div></div></div></blockquote></div><blockquote type="cite"><div dir="ltr"><div><div><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/" target="_blank">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"></pre></div></div></div></blockquote></span><div>&lt;snip&gt;</div><span><blockquote type="cite"><div dir="ltr"><div><div><pre style="white-space:pre-wrap;color:rgb(80,0,80);font-size:12.8px"><span style="font-family:monospace,monospace;font-size:12.8px">makeIncrementer(forIncrement: ^(number: Int) {</span></pre><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></div></div></div></blockquote></span><div>Why does the block now have to be declared within the function parameters?</div><div>Why do I have to declare the type of number now?</div><div>Why do I *not* have to declare the return type as being a boolean?</div><div>Would this syntax still support single expression implicit returns, e.g. current Swift</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo">&gt; [1,2,3].map() { number in number == 3 }</div></div></div><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(52,187,199)">$R0: [Bool] = 3 values {</div></div></div><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(52,187,199)">  [0] = false</div></div></div><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(52,187,199)">  [1] = false</div></div></div><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(52,187,199)">  [2] = true</div></div></div><div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(52,187,199)">}</div></div></div></blockquote><div><span><blockquote type="cite"><div dir="ltr"><div><div><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></div></div></div></blockquote></span><div>There are three pieces at play here IMHO:</div><div>1. How functions (global and on types) are declared and implemented</div><div>2. How function specifications are indicated as types</div><div>3. How anonymous functions are declared and implemented</div><div><div><div><br></div><div>When I declare a global or type-specific function, I can specify its name and arguments, assign external names to them (as well as internal names), and declare my return value. The types, even if generic, must be known for the function implementation to pass semantic checks.</div><div><br></div><div>The syntax for functions as types are really just a list of input and output types. There are not (for instance) named parameter requirements on the implementing functions. But the input and return types must be known to declare a new function type.</div><div><br></div><div>Anonymous functions assume a great deal of type information from the context in which they are used. This is why you can get away with not declaring input types or even input names (using $0, $1, etc), the return type or even if a value is returned. The code is mapped into the context it is needed, then semantic evaluation is done.</div></div></div><div><br></div>You are attempting to change #2 and #3 at the same time, when really they have quite different needs. I assume the reason anonymous functions (aka closures in Swift) have their argument names on the inside of the block is because the argument names have no external bearing whatsoever. Considering I may or may not declare type information or even give all the parameters names, this makes a certain kind of sense. If you were to move the argument names outside the block, you would need a syntax specifically for that. There are enough options that reusing the same base syntax between 1 and 3 or 2 and 3 would likely just _feel_ wrong.</div><div><br></div><div>There are enough rules about escape analysis to possibly make sense to have function blocks, do blocks, repeat blocks, switch blocks, for…in blocks, etc all be considered ‘kinds’ of blocks, and for closure blocks to be on that list. It possibly makes sense for them to have a keyword just like all the other blocks to simplify compiler and human visual parsing. But I don’t envy the effort of redesigning and redecorating that particular bike shed :-)</div><span><font color="#888888"><div><br></div><div>-DW</div></font></span></div></blockquote></div><br></div></div>