Hacker News Reader

Comment by masklinn | Hacker News Reader

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