Nope, the lifetime implications are a completely separate dimension. You can still have closures that don't retain any reference to variables with different lifetimes, e.g. using `[=]` in C++ or `move` in Rust.

Also, we don't have a separate name for structs that contain references/pointers and structs that don't do we?

> Also, we don't have a separate name for structs that contain references/pointers and structs that don't do we?

Languages name things they need to help their implementation. In Go, such types are named ("pointer-ful" and "pointer-free"), because they are allocated differently to assist GC. In C++, they're not but instead we have e.g. PODs which other languages don't need to name, because of other optimizations C++ wants to do.

We don't because those pointers are explicit. But they're not with closures, even with something as low-level as [&] in C++.

And, yes, what [=] produces is not a closure, by definition (but it's still a lambda).

Sorry, why wouldn't closing over a variable by value count as a closure? In fact in many functional languages you can't tell the difference.

In functional languages where you can't tell the difference, like ML or Haskell, values are bound directly to variables, so capturing the value is closing over the variable. But in C++, variables represent storage locations which contain values, so if you copy the value, you're not really closing over the variable (unless it's const).

To look at it from another perspective, if a closure closes over the variable, then references to that variable inside the closure should behave the same as references to that variable outside of it. If you can change the variable value outside, and it's not reflected inside the closure, then it's not really the same variable inside and outside.