> On Dec 29, 2015, at 5:18 PM, Ethan Diamond via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
