Exploring some code changes on a branch in Axom, I'm seeing compiler warnings that implicitly capturing this in a lambda expression is deprecated in C++20. Specifically, we are using the macros defined here in the code: https://github.com/llnl/axom/blob/develop/src/axom/core/Macros.hpp#L78
The warnings don't show up in Axom develop currently, but I expect that Axom developers and users will also run into these warnings at some point.
In C++20, [=, this] is valid and well-formed (prior to C++20, it was either redundant or not considered valid depending on the compiler). However, this only works when a lambda expression is used within a class/struct member function.
To avoid confusing inconsistent syntax, having multiple lamda macros for different code use cases, or macros that don't do anything, my suggestion would be to remove the AXOM_*_LAMBDA macros and make the capture syntax required. Currently, we have [=] in all the macros. FWIW, I don't see the reason for having capture-by-value (i.e., [=]) in a lambda expression that isn't used for device code. In fact, I would argue that it makes the lambda expression less useful for host-only code, because you can't modify anything that is captured inside the lambda expression.
Exploring some code changes on a branch in Axom, I'm seeing compiler warnings that implicitly capturing
thisin a lambda expression is deprecated in C++20. Specifically, we are using the macros defined here in the code: https://github.com/llnl/axom/blob/develop/src/axom/core/Macros.hpp#L78The warnings don't show up in Axom develop currently, but I expect that Axom developers and users will also run into these warnings at some point.
In C++20,
[=, this]is valid and well-formed (prior to C++20, it was either redundant or not considered valid depending on the compiler). However, this only works when a lambda expression is used within a class/struct member function.To avoid confusing inconsistent syntax, having multiple lamda macros for different code use cases, or macros that don't do anything, my suggestion would be to remove the
AXOM_*_LAMBDAmacros and make the capture syntax required. Currently, we have[=]in all the macros. FWIW, I don't see the reason for having capture-by-value (i.e.,[=]) in a lambda expression that isn't used for device code. In fact, I would argue that it makes the lambda expression less useful for host-only code, because you can't modify anything that is captured inside the lambda expression.