Hacker News Reader

Comment by Joker_vD | Hacker News Reader

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.

View on HN

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