<p>The current syntax is clumsy, I would love to see a reduced, better readable way to write anonymous functions.</p>
<p>Current:</p>
<pre><code>type someFn func(int, int) int
func foo(n int) someFn {
return func(a, b int) int {
return a + b + n
}
}
</code></pre>
<p>Using the "type alias" could be an improvment.</p>
<pre><code>func foo(n int) someFn {
return someFn{
return a + b + n
}
}
</code></pre>
<p>Keeping somewhat the function signature would be not bad. Therefore lets try to keep it, but still remove some clutter. Lets start with not having to type <code>func()</code> at the beginning of every anonymous function.</p>
<pre><code>func foo(n int) someFn {
return (a, b int) int {
return a + b + n
}
}
</code></pre>
<p>Since the return type of the function is known, I would love to not have to write <code>return ...</code> inside the anonymous function. If the function returns a value, just return the last computed value (for early-return, use the return keyword).</p>
<pre><code>func foo(n int) someFn {
return (a, b int) int {
a + b + n
}
}
</code></pre>
<p>The function signature is know in the case of someFn, therefore an <strong>alternative</strong> anonymous function syntax would be nice, replacing <code>(a, b int) int {...</code> with <code>{a, b int ->...</code>.</p>
<pre><code>func foo(n int) someFn {
return {a, b int ->
a + b + n
}
}
</code></pre>
<p>It would be even possible to remove the <code>int</code> part of the signature.</p>
<pre><code>func foo(n int) someFn {
return {a, b ->
a + b + n
}
}
</code></pre>
<p>Some languages – like Kotlin – have an optional dedicated variable name for anonymous function with only one parameter called <code>it</code> (it stands for item).</p>
<pre><code>func addOneFn() func(int) int {
return { it + 1 } // instead of: { x -> x +1 }
}
</code></pre>
<p>What do you think, does go need a better syntax and how should it look?</p>
<hr/>**评论：**<br/><br/>TheMerovius: <pre><blockquote>
<p>What do you think, does go need a better syntax</p>
</blockquote>
<p>No. This is, if anything, a very minor issue (I don't consider the current syntax "clumsy", at all) and not worth complicating the language. Pretty much everything you suggest would significantly complicate the parser and spec. </p></pre>Paradiesstaub: <pre><blockquote>
<p>Pretty much everything you suggest would significantly complicate the parser and spec.</p>
</blockquote>
<p>I see your point of being okay with the current syntax. But the "would complicate the parser" part is kind of strange to me, because that's an argument against every change.</p></pre>TheMerovius: <pre><blockquote>
<p>But the "would complicate the parser" part is kind of strange to me, because that's an argument against every change.</p>
</blockquote>
<p>a) That's not true, there is the possibility to simplify the parser with a change.</p>
<p>b) Even if it where true, not every change complicates it <em>significantly</em>. You are suggesting removing a bunch of keywords from certain parts of the language, which means the parser now needs to infer from the context what was meant, by looking at more tokens and add a bunch of extra logic. Keywords serve an important purpose in the language, as they can remove context-sensitivity from the language.</p>
<p>c) And lastly, yes, it is an argument against most changes. Meaning, every change needs to have benefits that outweigh this argument against them.</p></pre>callcifer: <pre><blockquote>
<p>that's an argument against every change.</p>
</blockquote>
<p>That's exactly why a lot of "improvements" like these get rejected all the time. Anything that complicates the parser without a <em>significant</em> benefit to the language is automatically rejected.</p>
<p>What you are proposing is an alternative syntax for doing the same thing, which Go avoids almost everywhere (e.g, <code>{</code> on the same line as <code>if</code>, only <code>for</code> for loops - no <code>do</code> or <code>while</code>, no ternary operators). </p></pre>LimEJET: <pre><p>The thing with Go is that there are no syntax alternatives. That's what makes the spec so small and the language so simple to pick up.</p>
<p>A function looks like a function, no matter where it appears.</p></pre>andradei: <pre><p>> The thing with Go is that there are no syntax alternatives</p>
<p>Except for variable definition. Which Rob Pike said should go away, but it's too late to do so.</p>
<p>var n int = 5
var n = 5
n := 5</p></pre>LimEJET: <pre><p>Indeed. The shorthand is nice though, and you end up using each type in specific situations:</p>
<ul>
<li>Globals: <code>var thing = 1</code></li>
<li>Locals without assignment: <code>var thing int</code></li>
<li>Locals with assignment: <code>thing := 1</code></li>
</ul>
<p>And the last one (<code>var thing int = 1</code>) only gets used when type inference would fail.</p></pre>peterbourgon: <pre><p>These all seem like much worse options.</p></pre>PsyWolf: <pre><p>I strongly recommend watching Rob Pike's talk <a href="https://www.youtube.com/watch?v=rFejpH_tAHM" rel="nofollow">Simplicity is Complicated</a>. The whole thing is worth watching but <a href="https://youtu.be/rFejpH_tAHM?t=311" rel="nofollow">this part</a> in particular is the main reason go doesn't have 2 different ways to declare functions (or do much else for that matter). </p>
<p>Anonymous function declarations look almost exactly like normal function declarations. No special "->" or "/" lambda syntax. No implicit dedicated variables like "it". It's just the same boring syntax you use everywhere else but without the function name. Not having 2 different ways to do everything is why we love this language. We wont change that to save a few keystrokes.</p></pre>Paradiesstaub: <pre><p>The talk about simplicity was very interesting, thanks for posting the link!</p></pre>flat20: <pre><p>I think these examples sound like something your favourite editor could expand into go code.</p></pre>justinisrael: <pre><p>I really appreciate the clarity of the way it is now. To me, having alternate context based syntax is more cognitive load. I prefer the smaller language and the consistency. A function always reads as a function. </p></pre>dlsniper: <pre><p>I can currently extract every anonymous function into a function or method pretty much with a few small changes to the signature only. What you propose is just more work down the road for a few saved keystrokes. Imho you should learn more about the editor you are using and find out how you can do that with it.</p></pre>trisjpheck: <pre><p>Bikeshedding in action.</p></pre>ultra_brite: <pre><p>why do you bother with all this? the syntax isn't going to change whether you want it or not. The mailing list is full of feature discussions that went nowhere because Go maintainers refuse to change the syntax of the language.</p></pre>Paradiesstaub: <pre><p>Why, because I use closures and think that I type too much to get one.</p></pre>mistretzu: <pre><p><a href="http://www.keybr.com" rel="nofollow">This approach</a> might be more pragmatic than trying to change the go syntax :)</p></pre>ultra_brite: <pre><p>But Go maintainers don't care, they won't change the language so you can save key strokes. There is a ton of more useful proposals out there and they are all rejected by the Go team, because they don't wont to change the language that's all there is to it. Don't waste your time and accept that Go won't change ... or use something else.</p></pre>
