<p>A lot of languages have anonymous functions, also known as lambda functions. Anonymous, in-line, functions that can be used inside expressions for things like mapping and filtering.</p>
<p>What are common syntax options for lambdas, and what are their pros and cons?</p>

<syntax><functions><lambda>
What are common options for lambda function syntax?
CC BY-SA 4.0
2023-05-18T17:20:29.567Z
Closures are not the same thing as lambdas at all
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T17:21:23.827Z
A closure is any function that uses variables from a outer scope, a lambda is just a function without a name
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T17:26:39.353Z
@mousetail fixed, whoops
Ginger
CC BY-SA 4.0
2023-05-18T17:27:02.887Z
You changed it to the wrong thing, the text is all about lambdas not closures now.
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T19:22:06.613Z
If you don't want explicit control over closures, I'd say reusing the function syntax (except allowing to omit the name) is a nice approach. One less grammar item for the programmer to remember
abel1502
CC BY-SA 4.0
2023-05-19T09:24:42.787Z
what does "common" mean? can you define it systematically?
starball
<h1>Swift-style</h1>
<p>If you haven’t seen it yet, let me introduce you to <a href="https://fuckingclosuresyntax.com" rel="nofollow noreferrer">https://fuckingclosuresyntax.com</a>.</p>
<p>More seriously, the full syntax is this:</p>
<pre class="lang-swift prettyprint-override"><code>{ [byValueCapture] (argName: ArgType) -&gt; ReturnType in body }
</code></pre>
<p>…but <em>most</em> of that is optional.</p>
<p>A few things to note:</p>
<ul>
<li>Only by-value captures are specified; by-reference captures are implicit.</li>
<li>Unlike in C++, the square brackets are omitted when there are no captures.</li>
<li>The argument types are optional if the type checker can infer them.</li>
<li>The return type and <code>-&gt;</code> are optional if the type checker can infer it, but must be together; you can’t have one without the other.</li>
<li>If the argument types and return type are omitted, the parentheses around the argument list are optional.</li>
<li>If the argument types and return type are omitted, the arguments do not need to be named; their names default to <code>$0</code> for the first argument, <code>$1</code> for the second argument, and so on.</li>
<li>If there’s nothing before the word <code>in</code> (it’s all implied or unnecessary), that word must be omitted, too.</li>
</ul>
<p>There’s also a shorthand for property access known as a <em>key-path expression</em>; these expressions are equivalent<sup>1</sup>:</p>
<pre class="lang-swift prettyprint-override"><code>{ (x: MyClass) in x.foo }
\MyClass.foo
\.foo // when the argument type can be inferred
</code></pre>
<p>This can lead to some nice abbreviations, such as:</p>
<pre class="lang-swift prettyprint-override"><code>let names = people.map(\.name)
</code></pre>
<p>Key-path expressions even support optional chaining, so <code>\.output.first?.substring</code> is valid and equivalent to <code>{ $0.output.first?.substring }</code>.</p>
<p>Of course, the wide variation in everything causes some confusion, hence the existence of the aforementioned website.</p>
<p><sup>1</sup> Save for <a href="https://forums.swift.org/t/code-size-difference-with-keypath-vs-closure/61599" rel="nofollow noreferrer">compiler oddities</a>.</p>

CC BY-SA 4.0
2023-05-18T17:33:27.400Z
2023-08-01T13:42:36.597Z
2023-08-01T13:42:36.597Z
Bbrk24
CC BY-SA 4.0
2023-08-02T12:16:42.953Z
SFW mirror of the linked site (you know which one) for anyone else reading this on their work machine lol http://goshdarnclosuresyntax.com/
Jared Smith
<h1>Scala Style</h1>
<p>Welcome to the kitchen sink of lambda syntax! <em>All</em> of the following are valid in Scala and produce an anonymous function which adds one to its argument.</p>
<pre><code>x =&gt; x + 1
(x: Int) =&gt; x + 1
{ x =&gt; x + 1 }
{ x: Int =&gt; x + 1 }
_ + 1
</code></pre>

CC BY-SA 4.0
2023-05-18T20:44:26.570Z
2023-05-18T20:44:26.570Z
Silvio Mayolo
CC BY-SA 4.0
2023-07-21T17:57:35.157Z
There's also `1.+` and `1.+(_)`, since `+` is simply a method on `Int`s
user
<h1>APL style</h1>
<p>APLs (APL, J, K, BQN) have lambdas that are are unique in having a pre-defined set of argument names. E.g. APL uses prefix/infix lambdas with <code>⍺</code> for the left argument (optional) and <code>⍵</code> for the right argument. Here, we define a root function (<code>*</code> is exponentiation and prefix <code>÷</code> is reciprocal):</p>
<pre><code>      2 {⍵*÷⍺} 100
10
</code></pre>
<p>A lambda can be ambivalently prefix/infix by either checking if a left argument is present, or by using the convention that an attempted assignment to <code>⍺</code> is ignored if <code>⍺</code> already has a value (<code>⋄</code> is the statement separator):</p>
<pre><code>      Root←{⍺←2 ⋄ ⍵*÷⍺}
      Root 100
10
      3 Root 8
2
</code></pre>
<p>As with all APL functions, if many arguments are needed, they can be given as an array, one element per argument, and destructured inside the function. The destructuring expression then functions as a type of header (<code>⍳</code> is the range function):</p>
<pre><code>      {(start count step)←⍵ ⋄ start+step×⍳count} 10 5 2
10 12 14 16 18
</code></pre>
<p>Some APLs (K, BQN) have an explicit header syntax too, and BQN allows multiple headers for various uses, but this is the gist of it.</p>

CC BY-SA 4.0
2023-05-19T06:10:07.193Z
2023-05-19T06:10:07.193Z
Adám
<h1>Arrow style</h1>
<pre><code>(args) -&gt; body
</code></pre>
<p>This is subject to a lot of variation:</p>
<ul>
<li>Single vs. double arrow (<code>-&gt;</code> vs. <code>=&gt;</code>)</li>
<li>Args list styles (bare identifiers allowed for single arg lambdas, or require parens? destructuring? etc.)</li>
<li>Body may have to be wrapped in <code>{}</code>s, or single expressions may be allowed without those</li>
</ul>

CC BY-SA 4.0
2023-05-18T18:30:07.060Z
2023-05-18T18:30:07.060Z
rydwolf
<h1>Rust-style</h1>
<pre class="lang-rust prettyprint-override"><code>|parameters| -&gt; returntype {body}
</code></pre>
<p>This is a rather unorthodox form, as I think only Rust uses it. However, it may be less prone to syntactic ambiguity by virtue of not using curved brackets.</p>

CC BY-SA 4.0
2023-05-18T17:20:07.963Z
2023-05-18T17:20:07.963Z
Ginger
CC BY-SA 4.0
2023-05-18T18:28:17.190Z
I believe other languages do too...I think Ruby does? It's definitely somewhat common tho
rydwolf
CC BY-SA 4.0
2023-08-02T15:05:20.957Z
It's inspired by Ruby, but not the same; Ruby has the parameters inside the braces.
xigoi
CC BY-SA 4.0
2023-08-11T16:30:16.407Z
`| parameters |` appeared in Smalltalk, I think. See [this answer](https://langdev.stackexchange.com/a/2650/903).
Pablo H
<h1>ML style:</h1>
<pre><code>one arg
fun x -&gt; x

multiple arg
fun f xs -&gt; List.map f xs
==
fun f -&gt; fun xs -&gt; List.map f xs
</code></pre>

CC BY-SA 4.0
2023-05-18T23:09:34.447Z
2023-05-18T23:09:34.447Z
blueberry
<h2>PHP Style</h2>
<pre><code>fn (parameter1, parameter2) =&gt; value
</code></pre>
<p>It's the same as Javascript style except it also adds a required <code>fn</code> keyword before. Requiring a keyword makes things a bit more explicit which is nice but it's also more verbose.</p>
<p>There is no benefit of consistency because normal functions are defined with <code>function</code> not <code>fn</code>.</p>
<p>As VLAZ pointed out there is also a long form:</p>
<pre><code>$f = function ($b) use ($a) { return $a + $b; }
</code></pre>
<p>Which requires explicitly specifying what variables you want to capture</p>
<h2>Java Style</h2>
<pre><code>(parameter1, parameter2) -&gt; expression
</code></pre>
<p>It's the same as javascript except using <code>-&gt;</code> instead of <code>=&gt;</code></p>
<h2>Javascript Standard Style</h2>
<pre><code>function(argument_1, argument_2) { code }
</code></pre>
<p>JavaScript has 2 ways of defining closures. <code>this</code> is handled differently in both cases.</p>
<p>I like this one because of the symmetry of <code>function name() {}</code> for named functions and <code>function() {}</code> for anonymous functions. A shame about how <code>this</code> works or I'd prefer it over <code>()=&gt;{}</code></p>

CC BY-SA 4.0
2023-05-18T17:24:56.440Z
2023-05-18T17:51:46.063Z
2023-05-18T17:51:46.063Z
mousetail 'he-him'
CC BY-SA 4.0
2023-05-18T17:36:07.713Z
In PHP when using `function` you also need to import/capture values from outer scope(s), which the short `fn` does automatically. E.g., `$a = 1; $f = function ($b) use ($a) { return $a + $b; }` is the long and explicit capturing syntax, while with an arrow function it's `$a = 1; $g = fn($b) => $a + $b;`
VLAZ
<h1>Blocks</h1>
<p>Blocks are a clang extension to C enabled with the <code>-fblocks</code> flag, though they're more common in -- and therefore usually associated with -- Objective-C.</p>
<p>The type syntax is similar to function pointers: <code>return_type(^)(arg_types)</code>. These are typically used in typedefs, such as</p>
<pre class="lang-c prettyprint-override"><code>typedef int(^int_function_t)(int);
</code></pre>
<p>The full syntax for defining one is this:</p>
<pre class="lang-c prettyprint-override"><code>^return_type (arg_type arg_name) {
  body();
}
</code></pre>
<p>However, the return type can usually be inferred from the body of the block. If the return type is omitted and the argument list is <code>(void)</code>, that can be omitted, too. For example:</p>
<pre class="lang-c prettyprint-override"><code>int (^square)(int) = ^(int x) { return x * x; };
int (^randomNumber)(void) = ^{ return 4; };
</code></pre>
<p>NB: the trailing semicolon after the closing brace is necessary to end the declaration statement, and is not part of the block.</p>
<p>Blocks are called with the same syntax as function pointers.</p>
<p>If you need to capture a variable by reference, you must mark it with the <code>__block</code> storage specifier. Otherwise, capture by value is implicit:</p>
<pre class="lang-c prettyprint-override"><code>int x = 4;
__block int y = 4;

void (^printX)(void) = ^{ printf(&quot;%d\n&quot;, x); };
void (^printY)(void) = ^{ printf(&quot;%d\n&quot;, y); };

++x;
++y;

printX(); // prints '4'
printY(); // prints '5'
</code></pre>

CC BY-SA 4.0
2023-05-18T21:28:52.893Z
2023-05-18T21:28:52.893Z
Bbrk24
<h1>Kotlin style</h1>
<p>The full syntax is</p>
<pre><code>{ a: Foo, b: Bar -&gt; body() }
</code></pre>
<p>The type annotations may be omitted, and if there is only one parameter, that can be omitted and replaced with the implicit parameter <code>it</code>:</p>
<pre><code>{ it.bar() }
</code></pre>

CC BY-SA 4.0
2023-05-18T18:12:38.487Z
2023-05-18T19:17:46.300Z
2023-05-18T19:17:46.300Z
Seggan
<h1>Haskell style</h1>
<pre><code>\a b -&gt; expr
</code></pre>
<p>Advantages:</p>
<ul>
<li>Concise: uses symbols instead of long keywords</li>
<li>The <code>\</code> symbol is a mnemonic for λ</li>
<li>Can be parsed unambiguously without requiring any brackets (but see below)</li>
</ul>
<p>Disadvantages:</p>
<ul>
<li>Might not be immediately clear to a language learner that this is a lambda function syntax</li>
<li>Usually must be wrapped in parentheses, because juxtaposing identifiers in Haskell represents function application (if <code>map \a b -&gt; c d</code> were legal syntax, it would parse as <code>map (\a b -&gt; (c d))</code> rather than <code>map (\a b -&gt; c) d</code>)
<ul>
<li>A language in which juxtaposed identifiers cannot be part of the same expression wouldn't have this problem</li>
</ul>
</li>
<li>Function body must be a single expression (not a problem in Haskell, but might be less desirable in an imperative language)</li>
</ul>

CC BY-SA 4.0
2023-05-18T21:45:31.937Z
2023-05-18T21:47:07.347Z
2023-05-18T21:47:07.347Z
DLosc
CC BY-SA 4.0
2023-05-18T21:46:55.717Z
`map \a b -> c` isn't even valid syntax, the parser requires parentheses. You can use it with `$` though
naffetS
CC BY-SA 4.0
2023-05-22T13:33:41.610Z
`map \a b -> c d` **is** valid syntax (and parses as `map (\a b -> c d)` with GHC, if you turn on [the `BlockArguments` language extension](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/block_arguments.html).
Cactus
<h2>JS style</h2>
<pre class="lang-js prettyprint-override"><code>(parameters) =&gt; body
</code></pre>
<p>Very concise. You can also have multiple statements if you wrap it in braces.</p>
<h2>Python style</h2>
<pre class="lang-python prettyprint-override"><code>lambda parameters: body
</code></pre>
<p>A bit verbose with the keyword <code>lambda</code>, and also only allows one expression.</p>
<h2>Ruby style</h2>
<pre class="lang-ruby prettyprint-override"><code>do |parameters| body end
</code></pre>
<p>Allows expressions or statements, but still a bit verbose.</p>
<p>Alternatively:</p>
<pre class="lang-ruby prettyprint-override"><code>{ |parameters| body }
</code></pre>
<p>More concise, and also allows expressions or statements.</p>
<h2>Perl style</h2>
<pre class="lang-perl prettyprint-override"><code>sub {my ($parameters) = @_; body};
</code></pre>
<p>Once again, allows expressions or statements, but it's even longer than Ruby.</p>
<h2>C++ style</h2>
<pre class="lang-cpp prettyprint-override"><code>[&amp;](parameters) {body}
</code></pre>
<p>Concise and allows multiple statements.</p>

CC BY-SA 4.0
2023-05-18T17:21:51.283Z
2023-08-02T16:09:23.400Z
2023-08-02T16:09:23.400Z
The Thonnu
CC BY-SA 4.0
2023-08-02T15:03:07.097Z
The braces in Ruby also allow multiple statements.
xigoi
CC BY-SA 4.0
2023-08-03T10:47:22.830Z
Haskell style: `\parameters -> expression` (e.g. `\x y -> x + y`)
md2perpe
<p>going back to the older ones:</p>
<h1>LISP style</h1>
<pre><code>(lambda (params) body)
</code></pre>
<h1>Smalltalk style</h1>
<pre><code>[| parameters | body ]
[ body ]     -- when there are no parameters
</code></pre>

CC BY-SA 4.0
2023-08-03T01:07:13.987Z
2023-08-03T01:07:13.987Z
Chris Dodd
<h1>Go-style</h1>
<p>Go uses the same function declaration syntax everywhere, and lambdas are just anonymous functions.</p>
<pre class="lang-go prettyprint-override"><code>func(){ body }
func() returnType { body }
func(parameters) { body }
func(parameters) returnType { body }
</code></pre>
<p>These syntaxes are equivalent, all declare a function and bind it to <code>FuncName</code>:</p>
<pre class="lang-go prettyprint-override"><code>func FuncName(){...}
var FuncName = func(){...}
FuncName := func(){...}
</code></pre>
<p>A common pattern is to use or call functions immediately after definitions, mainly for goroutines, <code>defer</code>, and initializing something with a complicated calculation:</p>
<pre class="lang-go prettyprint-override"><code>value := func(a,b,c) returnType { ... }(x,y,z)
go func() { ... }
defer func() { ... }
</code></pre>

CC BY-SA 4.0
2023-08-02T13:44:00.297Z
2023-08-02T13:44:00.297Z
bigyihsuan
# What are common options for lambda function syntax?
Posted by: username_0 on 2023-05-18
A lot of languages have anonymous functions, also known as lambda functions. Anonymous, in-line, functions that can be used inside expressions for things like mapping and filtering.

What are common syntax options for lambdas, and what are their pros and cons?
**Tags:** syntax functions lambda
> **Comments:**
> **username_1**: Closures are not the same thing as lambdas at all  
> **username_1**: A closure is any function that uses variables from a outer scope, a lambda is just a function without a name  
> **username_0**: @mousetail fixed, whoops  
> **username_1**: You changed it to the wrong thing, the text is all about lambdas not closures now.  
> **username_2**: If you don't want explicit control over closures, I'd say reusing the function syntax (except allowing to omit the name) is a nice approach. One less grammar item for the programmer to remember  
> **username_3**: what does "common" mean? can you define it systematically?  
---
## 13 answers
### Answer by username_4 on 2023-05-18. Score: 9
Swift-style
If you haven’t seen it yet, let me introduce you to https://fuckingclosuresyntax.com.
More seriously, the full syntax is this:
{ [byValueCapture] (argName: ArgType) -> ReturnType in body }

…but most of that is optional.
A few things to note:

Only by-value captures are specified; by-reference captures are implicit.
Unlike in C++, the square brackets are omitted when there are no captures.
The argument types are optional if the type checker can infer them.
The return type and -> are optional if the type checker can infer it, but must be together; you can’t have one without the other.
If the argument types and return type are omitted, the parentheses around the argument list are optional.
If the argument types and return type are omitted, the arguments do not need to be named; their names default to $0 for the first argument, $1 for the second argument, and so on.
If there’s nothing before the word in (it’s all implied or unnecessary), that word must be omitted, too.

There’s also a shorthand for property access known as a key-path expression; these expressions are equivalent1:
{ (x: MyClass) in x.foo }
\MyClass.foo
\.foo // when the argument type can be inferred

This can lead to some nice abbreviations, such as:
let names = people.map(\.name)

Key-path expressions even support optional chaining, so \.output.first?.substring is valid and equivalent to { $0.output.first?.substring }.
Of course, the wide variation in everything causes some confusion, hence the existence of the aforementioned website.
1 Save for compiler oddities.
> **Comments:**
> **username_5** (2023-08-02): SFW mirror of the linked site (you know which one) for anyone else reading this on their work machine lol http://goshdarnclosuresyntax.com/  
---
### Answer by username_6 on 2023-05-18. Score: 9
Scala Style
Welcome to the kitchen sink of lambda syntax! All of the following are valid in Scala and produce an anonymous function which adds one to its argument.
x => x + 1
(x: Int) => x + 1
{ x => x + 1 }
{ x: Int => x + 1 }
_ + 1
> **Comments:**
> **username_7** (2023-07-21): There's also `1.+` and `1.+(_)`, since `+` is simply a method on `Int`s  
---
### Answer by username_15 on 2023-05-18. Score: 8
Haskell style
\a b -> expr

Advantages:

Concise: uses symbols instead of long keywords
The \ symbol is a mnemonic for λ
Can be parsed unambiguously without requiring any brackets (but see below)

Disadvantages:

Might not be immediately clear to a language learner that this is a lambda function syntax
Usually must be wrapped in parentheses, because juxtaposing identifiers in Haskell represents function application (if map \a b -> c d were legal syntax, it would parse as map (\a b -> (c d)) rather than map (\a b -> c) d)

A language in which juxtaposed identifiers cannot be part of the same expression wouldn't have this problem


Function body must be a single expression (not a problem in Haskell, but might be less desirable in an imperative language)
> **Comments:**
> **username_16** (2023-05-18): `map \a b -> c` isn't even valid syntax, the parser requires parentheses. You can use it with `$` though  
> **username_17** (2023-05-22): `map \a b -> c d` **is** valid syntax (and parses as `map (\a b -> c d)` with GHC, if you turn on [the `BlockArguments` language extension](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/block_arguments.html).  
---
### Answer by username_18 on 2023-05-18. Score: 8
JS style
(parameters) => body

Very concise. You can also have multiple statements if you wrap it in braces.
Python style
lambda parameters: body

A bit verbose with the keyword lambda, and also only allows one expression.
Ruby style
do |parameters| body end

Allows expressions or statements, but still a bit verbose.
Alternatively:
{ |parameters| body }

More concise, and also allows expressions or statements.
Perl style
sub {my ($parameters) = @_; body};

Once again, allows expressions or statements, but it's even longer than Ruby.
C++ style
[&](parameters) {body}

Concise and allows multiple statements.
> **Comments:**
> **username_10** (2023-08-02): The braces in Ruby also allow multiple statements.  
> **username_19** (2023-08-03): Haskell style: `\parameters -> expression` (e.g. `\x y -> x + y`)  
---
### Answer by username_8 on 2023-05-19. Score: 7
APL style
APLs (APL, J, K, BQN) have lambdas that are are unique in having a pre-defined set of argument names. E.g. APL uses prefix/infix lambdas with ⍺ for the left argument (optional) and ⍵ for the right argument. Here, we define a root function (* is exponentiation and prefix ÷ is reciprocal):
      2 {⍵*÷⍺} 100
10

A lambda can be ambivalently prefix/infix by either checking if a left argument is present, or by using the convention that an attempted assignment to ⍺ is ignored if ⍺ already has a value (⋄ is the statement separator):
      Root←{⍺←2 ⋄ ⍵*÷⍺}
      Root 100
10
      3 Root 8
2

As with all APL functions, if many arguments are needed, they can be given as an array, one element per argument, and destructured inside the function. The destructuring expression then functions as a type of header (⍳ is the range function):
      {(start count step)←⍵ ⋄ start+step×⍳count} 10 5 2
10 12 14 16 18

Some APLs (K, BQN) have an explicit header syntax too, and BQN allows multiple headers for various uses, but this is the gist of it.
---
### Answer by username_9 on 2023-05-18. Score: 6
Arrow style
(args) -> body

This is subject to a lot of variation:

Single vs. double arrow (-> vs. =>)
Args list styles (bare identifiers allowed for single arg lambdas, or require parens? destructuring? etc.)
Body may have to be wrapped in {}s, or single expressions may be allowed without those
---
### Answer by username_0 on 2023-05-18. Score: 6
Rust-style
|parameters| -> returntype {body}

This is a rather unorthodox form, as I think only Rust uses it. However, it may be less prone to syntactic ambiguity by virtue of not using curved brackets.
> **Comments:**
> **username_9** (2023-05-18): I believe other languages do too...I think Ruby does? It's definitely somewhat common tho  
> **username_10** (2023-08-02): It's inspired by Ruby, but not the same; Ruby has the parameters inside the braces.  
> **username_11** (2023-08-11): `| parameters |` appeared in Smalltalk, I think. See [this answer](https://langdev.stackexchange.com/a/2650/903).  
---
### Answer by username_12 on 2023-05-18. Score: 6
ML style:
one arg
fun x -> x

multiple arg
fun f xs -> List.map f xs
==
fun f -> fun xs -> List.map f xs
---
### Answer by username_1 on 2023-05-18. Score: 5
PHP Style
fn (parameter1, parameter2) => value

It's the same as Javascript style except it also adds a required fn keyword before. Requiring a keyword makes things a bit more explicit which is nice but it's also more verbose.
There is no benefit of consistency because normal functions are defined with function not fn.
As VLAZ pointed out there is also a long form:
$f = function ($b) use ($a) { return $a + $b; }

Which requires explicitly specifying what variables you want to capture
Java Style
(parameter1, parameter2) -> expression

It's the same as javascript except using -> instead of =>
Javascript Standard Style
function(argument_1, argument_2) { code }

JavaScript has 2 ways of defining closures. this is handled differently in both cases.
I like this one because of the symmetry of function name() {} for named functions and function() {} for anonymous functions. A shame about how this works or I'd prefer it over ()=>{}
> **Comments:**
> **username_13** (2023-05-18): In PHP when using `function` you also need to import/capture values from outer scope(s), which the short `fn` does automatically. E.g., `$a = 1; $f = function ($b) use ($a) { return $a + $b; }` is the long and explicit capturing syntax, while with an arrow function it's `$a = 1; $g = fn($b) => $a + $b;`  
---
### Answer by username_4 on 2023-05-18. Score: 5
Blocks
Blocks are a clang extension to C enabled with the -fblocks flag, though they're more common in -- and therefore usually associated with -- Objective-C.
The type syntax is similar to function pointers: return_type(^)(arg_types). These are typically used in typedefs, such as
typedef int(^int_function_t)(int);

The full syntax for defining one is this:
^return_type (arg_type arg_name) {
  body();
}

However, the return type can usually be inferred from the body of the block. If the return type is omitted and the argument list is (void), that can be omitted, too. For example:
int (^square)(int) = ^(int x) { return x * x; };
int (^randomNumber)(void) = ^{ return 4; };

NB: the trailing semicolon after the closing brace is necessary to end the declaration statement, and is not part of the block.
Blocks are called with the same syntax as function pointers.
If you need to capture a variable by reference, you must mark it with the __block storage specifier. Otherwise, capture by value is implicit:
int x = 4;
__block int y = 4;

void (^printX)(void) = ^{ printf("%d\n", x); };
void (^printY)(void) = ^{ printf("%d\n", y); };

++x;
++y;

printX(); // prints '4'
printY(); // prints '5'
---
### Answer by username_14 on 2023-05-18. Score: 5
Kotlin style
The full syntax is
{ a: Foo, b: Bar -> body() }

The type annotations may be omitted, and if there is only one parameter, that can be omitted and replaced with the implicit parameter it:
{ it.bar() }
---
### Answer by username_20 on 2023-08-03. Score: 3
going back to the older ones:
LISP style
(lambda (params) body)

Smalltalk style
[| parameters | body ]
[ body ]     -- when there are no parameters
---
### Answer by username_21 on 2023-08-02. Score: 2
Go-style
Go uses the same function declaration syntax everywhere, and lambdas are just anonymous functions.
func(){ body }
func() returnType { body }
func(parameters) { body }
func(parameters) returnType { body }

These syntaxes are equivalent, all declare a function and bind it to FuncName:
func FuncName(){...}
var FuncName = func(){...}
FuncName := func(){...}

A common pattern is to use or call functions immediately after definitions, mainly for goroutines, defer, and initializing something with a complicated calculation:
value := func(a,b,c) returnType { ... }(x,y,z)
go func() { ... }
defer func() { ... }
---
