<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 29, 2015, at 5:18 PM, Ethan Diamond via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-size: 12.8px;" class="">I guess the core of the question for me is why have the concept of a closure at all when they're harder to read while acting the same way that functions do? I'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 class=""></div>Some of this is because Javascript doesn'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 class=""></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><br class=""><blockquote type="cite" class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-size: 12.8px;" class=""><span style="font-size: 12.8px;" class="">Let's take the anonymous function style:</span></div><div style="font-size: 12.8px;" class=""><br class=""></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class="">func asyncWithCallback(_ : func (String) -> Bool)</font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class=""><br class=""></font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class="">asyncWithCallback(func (param) {</font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class=""> return param == "string"</font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class="">})</font></div><div style="font-size: 12.8px;" class=""><br class=""></div><div style="font-size: 12.8px;" class="">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;" class=""><br class=""></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class="">func asyncWithCallback(_ : String -> Bool)</font></div><div style="font-size: 12.8px;" class=""><br class=""></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class="">asyncWithCallback {</font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class=""> (param: String) -> Bool in</font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class=""> return param == "string"</font></div><div style="font-size: 12.8px;" class=""><font face="monospace, monospace" class="">}</font></div></div></blockquote><div><br class=""></div>Or I could use:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(41, 76, 80);" class="">asyncWithCallback<span style="color: rgb(0, 0, 0);" class=""> {</span></div></div><div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""> param <span style="font-variant-ligatures: no-common-ligatures; color: #c32275" class="">in</span></div></div><div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: #c32275" class="">return</span> param == <span style="font-variant-ligatures: no-common-ligatures; color: #c91b13" class="">"string"</span></div></div><div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class="">}</div></div></blockquote><div><div style="margin: 0px; line-height: normal; font-family: Menlo; min-height: 21px;" class=""><br class=""></div><div style="margin: 0px; line-height: normal; font-family: Menlo; min-height: 21px;" class="">or even:</div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div style="margin: 0px; line-height: normal;" class=""><font color="#294c50" face="Menlo" class="">asyncWithCallback</font><span style="color: rgb(0, 0, 0); font-family: Menlo;" class=""> { $0 == </span><span style="color: rgb(201, 27, 19); font-family: Menlo;" class="">"string</span><font color="#c91b13" face="Menlo" class="">”</font><font face="Menlo" class=""> }</font></div></div></blockquote><font face="Menlo" class=""><div class=""><br class=""></div><div class="">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" 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 class=""><br class=""></div><div class="">However this new keyword would need to work with, and avoid adding visual distraction to, the “$0 == “string” case above.</div></font><div class=""><font face="Menlo" class=""><br class=""></font><div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-size: 12.8px;" class=""><br class=""></div><div style="font-size: 12.8px;" class="">It still fits your unwritten rule to be able to compose language features in Swift, assuming you leave the same syntactic sugar: <br class=""></div><div style="font-size: 12.8px;" class=""><pre style="white-space: pre-wrap;" class="">func if (_ control: Bool, _ path: func ()) {</pre><pre style="white-space: pre-wrap;" class=""> if (control) {</pre><pre style="white-space: pre-wrap;" class=""> path()</pre><pre style="white-space: pre-wrap;" class=""> }</pre><pre style="white-space: pre-wrap;" class="">}</pre><pre style="white-space: pre-wrap;" class="">if (a == b) {</pre><pre style="white-space: pre-wrap;" class=""> //LETS DO SOME STUFF</pre><pre style="white-space: pre-wrap;" class="">}</pre></div></div></div></blockquote>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.<br class=""></div><div><br class=""></div><div>-DW</div><br class=""></div></body></html>