Date: Tue, 22 Dec 2015 20:02:28 -0800
From: Jordan Rose <jordan_rose@apple.com>
To: Alexander Regueiro <alexreg@gmail.com>
Message-ID: <50B24AA4-D326-4FAD-822A-DDF8667ADE54@apple.com>We definitely thought a lot about closure syntax; what we ended up with
(a) is concise,
(b) has some precedent, structurally (Ruby, Smalltalk),
(c) is easy to parse (does not require unbounded lookahead) and therefore easier to produce diagnostics for, and
(d) kept the parameter list and return values looking like they do in declarations (when types are included)It may not be the prettiest thing in the language, but I'm not sure
why any of your proposals are objectively better. The main thing we
are missing is that closures do not look like standalone function
declarations, but we decided that they're important enough that they
need a lightweight syntax. (Compare with JavaScript for a language
that did not prioritize this.)
FWIW when I first saw (Swift 1.x) how closure syntax differs from
function syntax I tried to write up a proposal to unify them, but
arguments against doing so were convincing.
The `in` was the hardest part to get used to, but now it's done and I
can't really think of any symbol being less confusing.
I personally love trailing closures, both here and in Ruby, so I'd
put that down to just as much a matter of opinion as closure syntax.
I love trailing closures for their convenience, especially when calling
GCD. In fact, I wouldn't be offended if _two_ trailing closures were
possible: :-)
DuplexIOHandler(stream) { inputdata in
// handle input
}, { outputdata in
// handle output
}
···
On 23/12/15 2:01 , swift-evolution-request@swift.org wrote:
--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."