Hacker News Reader

Hacker News

Comment by tezza | Hacker News Reader

Parent Full thread

tezza

Yep, bitten by this one on repeat myself. definitely a WTF moment each time.

View on HN

same here, happened several times when launching a goroutine inside the loop

the fix was usually adding x := x

before go func() { do something with x }

A common alternative fix is to use IIFE, since the expression must be a call.

`go` evaluates everything but the final function call in the context of the caller. So

    go func (x int) { … } (x)

Will do the same, and is easier to extract to a named function.

The latter is also easier to re-inline accidentally because

    go func (x int) { do_work(x) } (x)

seems like a very roundabout way to say

   go do_work(x)

The "x := x" solution too suffers from this problem but slightly less: both idioms look like they are no-ops (while they are actually not) but at least "x := x" is weird enough to look like it was a deliberate choice, not some vestige from refactoring.

Er… it makes no difference?

Your first version is in fact a worse way to write the second one.

Huh. Now the closure-capturing in Go makes even less to me: instead of capturing the variable's current value it captures the variable itself i.e. puts &x into the closure instead of x — and no other piece of Go does that, although I was sure "go fun(args)" passed args by-ref but apparently not.

What's even the point of capturing the variable itself? To allow for writing inline callbacks that could sneakily mutate loop-local variables?

More generally allow the closure to write to its environment. That is the normal behaviour of closures in imperative langages, Java being the major exception because it rejects closing over non-final variable (and obviously that only blocks assignment, if the object is mutable you can do what you want to it).

In c++ close by value/reference is under programmer control and there is no default

What would be the use of closing over the value rather than the variable? That would stop a lot of interesting use of closed-over variables (like persisting values from call to call).

In fairness while that would be a lot less convenient in reference-based langages in Go you could just close over a pointer to the variable, making the relationship explicit.

That’s how you’d do it using a [=] lambda in c++ or a move closure in rust.

Reply on news.ycombinator.com