[swift-evolution] Closure Syntax

[David Waite]

> On Dec 29, 2015, at 5:18 PM, Ethan Diamond via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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. 

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.

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.

> Let's take the anonymous function style:
> 
> func asyncWithCallback(_ : func (String) -> Bool)
> 
> asyncWithCallback(func (param) {
>     return param == "string"
> })
> 
> 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:
> 
> func asyncWithCallback(_ : String -> Bool)
> 
> asyncWithCallback {
>   (param: String) -> Bool in
>   return param == "string"
> }

Or I could use:
asyncWithCallback {
    param in
    return param == "string"
}

or even:
asyncWithCallback { $0 == "string” }

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. 

However this new keyword would need to work with, and avoid adding visual distraction to, the “$0 == “string” case above.

> 
> It still fits your unwritten rule to be able to compose language features in Swift, assuming you leave the same syntactic sugar: 
> func if (_ control: Bool, _ path: func ()) {
>   if (control) {
>      path()
>   }
> }
> if (a == b) {
>   //LETS DO SOME STUFF
> }
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.

-DW

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151229/1e7d702f/attachment.html>