3 ms·
> On the flip side, an optional capture list could be a good compromise. That is exactly what I am thinking about. Or, rather, what C++ has done right: You can
by netheril96 10y ago
> On the flip side, an optional capture list could be a good compromise.
That is exactly what I am thinking about. Or, rather, what C++ has done right: You can let the compiler infer what to capture, like [=] or [&], or you can explicitly list the variables to capture.
> you need the ability to specify that the "captured" variable ought to be copied rather than actually captured
Yes, that is what I am talking about, and again, what C++ has done right. Most other languages give you no choice whether the capture is by copy or by reference.
- groovy2shoes 10y agoAh, then I see we're in agreement :) > Most other languages give you no choice whether the capture is by copy or by reference. That's because in languages that have traditionally had GC (i.e., languages in the Lisp tradition or in the ML tradition), the distinction didn't matter. Those languages did not "suffer" from a value/reference dichotomy (e.g., in Scheme, you're literally capturing the variable rather than a copy or reference to the value stored within -- under the hood, that variable might always store a reference for convenience, or it might store a value for performance, but it doesn't matter as it's strictly an implementation detail). I'm glad that the C++ committee didn't just dump closures into the language without considering this sort of interaction with other aspects of the language. Without the capture lists, closures in C++ have the potential to really suck. That the explicit capture lists even exist is evidence that they've carefully considered how the new features are going to play with existing characteristics of C++. Kudos to them for that!