[swift-evolution] Lambda function syntax

[Rainer Brockerhoff]

On 23/12/15 2:01 , swift-evolution-request at swift.org wrote:
> Date: Tue, 22 Dec 2015 20:02:28 -0800
> From: Jordan Rose <jordan_rose at apple.com>
> To: Alexander Regueiro <alexreg at gmail.com>
> Message-ID: <50B24AA4-D326-4FAD-822A-DDF8667ADE54 at 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
}

-- 
Rainer Brockerhoff  <rainer at brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/