Okay, I assume you are aware this essentially the same syntax as used in
languages like C# and Python, yes? I’m not sure there are any problems in those
languages with it.
> If you dig through (very early) history you’ll see that we had this. There
> are a couple of problems with it:
>
> 1) It punishes simple cases like “X.sort { $1 < $0 }”, along with lots of
> simple map and filter closures.
Not really. The above example would just be `X.sort func { $1 < $0 }” or
"X.sort \ { $1 < $0 }` in my proposed syntax. Also, it would be nice to have
all operators implicitly convertible to functions, or at the very least have
corresponding function definitions for all built-in & standard library
operators. Haskell does this really nicely (functions and operators are
basically interchangeable, and either can be used in prefix or infix mode).
Anyway, your above example might look something like `X.sort (>)` (since `(<)`
would take arguments in the opposite order).
> 2) It reads really weird in trailing closure cases.
Honestly, I strongly dislike trailing closures. I don’t think they add much,
and moreover they use a confusing syntax that make the whole function call look
superficially like a function declaration (or indeed the whole thing being a
closure).
> Lets step back: What problems are you trying to solve with the current
> closure syntax?
Readability, mainly. I think this is a big improvement. Also, consistency of
semantics. Everything else between curly braces represents a list of statements
and is conceptually the “body” of something (a function, a conditional, a
loop). The current closure syntax rather embeds the head into the body! Then
there’s similarity with other languages, which is minor, but nice. I don’t know
any language that uses a syntax like the current one of Swift.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
