You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that the rule "if the condition is not value-dependent after its instantiation" mainly affects implicit lambda captures of generic lambdas.
If I understand correctly, the intent is that the condition may still remain value-dependent when determining implicit lambda captures but won't be value-dependent after the instantiation of the lambda body. Should we add a proper example explaining this?
Here's an example, adjusted from the discussions on P0292R2 in Oulu. Would you like to see this in the standard?
template<class T>
int f(T x) {
int v = 10;
auto lam = [&] (auto a) {
if constexpr (sizeof(T) > 1)
++v;
};
lam(5);
return 0;
}
int v = f('a'); // "v" is not captured
Here's an example, adjusted from the discussions on P0292R2 in Oulu. Would you like to see this in the standard?
template<class T>
int f(T x) {
int v = 10;
auto lam = [&] (auto a) {
if constexpr (sizeof(T) > 1)
++v;
};
lam(5);
return 0;
}
int v = f('a'); // "v" is not captured
I guess it might be better to have two examples, one doesn't captures the outer variable like this, and the other captures it because the condition in if constexpr depends on the type of the generic lambda parameter.
It seems that the rule "if the condition is not value-dependent after its instantiation" mainly affects implicit lambda captures of generic lambdas.
If I understand correctly, the intent is that the condition may still remain value-dependent when determining implicit lambda captures but won't be value-dependent after the instantiation of the lambda body. Should we add a proper example explaining this?
CC-ing @jensmaurer @zygoloid
The text was updated successfully, but these errors were encountered: