Why is a const variable sometimes not required to be captured in a lambda?

Question

Consider the following example:

#include <cstdlib> int main() { const int m = 42; [] { m; }(); // OK const int n = std::rand(); [] { n; }(); // error: 'n' is not captured }

Why do I need to capture n in the second lambda but not m in the first lambda? I checked section 5.1.2 (Lambda expressions) in the C++14 standard but I was unable to find a reason. Can you point me to a paragraph in which this is explained?

Update: I observed this behavior with both GCC 6.3.1 and 7 (trunk). Clang 4.0 and 5 (trunk) fails with an error in both cases (variable 'm' cannot be implicitly captured in a lambda with no capture-default specified).

Same reason why std::array<int,m> is OK and std::array<int,n> is not. — n. m. could be an AI
– n. m. could be an AI, Commented Apr 18, 2017 at 9:57
I wish that variables weren't constexpr unless you explicitly specify it. If someone wants constexpr variable then one should declare it as one. — xinaiz
– xinaiz, Commented Apr 18, 2017 at 11:30
@BlackMoses: m isn't constexpr, it's a compile-time constant integral expression... which was a thing long before the constexpr keyword was dreamt up. — Ben Voigt
– Ben Voigt, Commented Apr 18, 2017 at 16:57

M.M · Accepted Answer · 2017-04-18 11:00:23Z

For a lambda at block scope, variables meeting certain criteria in the reaching scope may be used in limited ways inside the lambda, even if they are not captured.

Roughly speaking, reaching scope includes any variable local to the function containing the lambda, that would be in scope at the point the lambda was defined. So this includes m and n in the above examples.

The "certain criteria" and "limited ways" are specifically (as of C++14):

Inside the lambda, the variable must not be odr-used, which means it must not undergo any operation except for:
- appearing as a discarded-value expression (m; is one of these), or
- having its value retrieved.
The variable must either be:
- A const, non-volatile integer or enum whose initializer was a constant expression, or
- A constexpr, non-volatile variable (or a sub-object of such)

References to C++14: [expr.const]/2.7, [basic.def.odr]/3 (first sentence), [expr.prim.lambda]/12, [expr.prim.lambda]/10.

The rationale for these rules, as suggested by other comments/answers, is that the compiler needs to be able to "synthesize" a no-capture lambda as a free function independent of the block (since such things can be converted to a pointer-to-function); it can do this despite referring to the variable if it knows that the variable would always have the same value, or it can repeat the procedure for obtaining the variable's value independent of the context. But it can't do this if the variable could differ from time to time, or if the variable's address is needed for example.

In your code, n was initialized by a non-constant expression. Therefore n cannot be used in a lambda without being captured.

m was initialized by a constant expression 42, so it does meet the "certain criteria". A discarded-value expression does not odr-use the expression, so m; can be used without m being captured. gcc is correct.

I would say that the difference between the two compilers is that clang considers m; to odr-use m, but gcc does not. The first sentence of [basic.def.odr]/3 is quite complicated:

A variable x whose name appears as a potentially-evaluated expression ex is odr-used by ex unless applying the lvalue-to-rvalue conversion to x yields a constant expression that does not invoke any non-trivial functions and, if x is an object, ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion is applied to e, or e is a discarded-value expression.

but upon reading closely it does specifically mention that a discarded-value expression does not odr-use the expression.

C++11's version of [basic.def.odr] originally did not include the discarded-value expression case, so clang's behaviour would be correct under the published C++11. However the text that appears in C++14 was accepted as a Defect against C++11 (Issue 712), so compilers should update their behaviour even in C++11 mode.

I think [expr]/11 means that the lvalue-to-rvalue conversion is not applied in this case.
@cpplearner I didn't see that earlier but I agree with you now that you pointed it out , thanks ... will update my answer
Reading again, it seems whether m; performs lvalue-to-rvalue conversion is irrelevant. The definition of odr-use in [basic.def.odr]/3 says "either the lvalue-to-rvalue conversion is applied to e, or e is a discarded-value expression", and here the expression m is a discarded-value expression, so in the end the variable m is not odr-used.
@cpplearner Roger, I misread "discarded-value expression" as "unevaluated expression"

Beginner · Accepted Answer · 2017-04-18 11:06:41Z

Its because it is a constant expression, the compiler treats is as if it were [] { 42; }();

The rule in [expr.prim.lambda] is:

If a lambda-expression or an instantiation of the function call operator template of a generic lambda odr-uses (3.2) this or a variable with automatic storage duration from its reaching scope, that entity shall be captured by the lambda-expression.

Here a quote from the standard [basic.def.odr]:

A variable x whose name appears as a potentially-evaluated expression ex is odr-used unless applying the lvalue-to-rvalue conversion to x yields a constant expression (...) or e is a discarded-value expression.

(Removed not so important part to keep it short)

My simple understanding is: the compiler knows that m is constant at compile-time, whereas n will change at run-time and therefore n has to be captured. n would be odr-used, because you have to actually take a look at what is inside n at run time. In other words the fact that "there can be only one" definition of n is relevant.

This is from a comment by M.M:

m is a constant expression because it's a const automatic variable with constant expression initializer, but n is not a constant expression because its initializer was not a constant expression. This is covered in [expr.const]/2.7. The constant expression is not ODR-used, according to first sentence of [basic.def.odr]/3

See here for a demo.

It would be good to explain in a bit more detail why n; odr-uses n, but m; does not odr-use m
I fail to see how that paragraph is relevant as it says that the entity shall be captured by the lambda expression. In the first lambda, there is no capture, and yet GCC compiles it.
@s3rvac See comment by M.M The key here is that in one case there is odr-usage, but not in the other.
@IlyaPopov The variables are used in the same way in both lambdas, so I fail to see why there should be odr-usage in one lambda and not in the other lambda.
@s3rvac the paragraph says "If [conditions are met], that entity shall be captured". The conditions are met for n but not m.

eerorika · Accepted Answer · 2017-04-18 09:27:55Z

EDIT: The previous version of my answer was wrong. Beginner's is correct, here is relevant standard quote:

[basic.def.odr]

A variable x whose name appears as a potentially-evaluated expression ex is odr-used by ex unless applying the lvalue-to-rvalue conversion to x yields a constant expression that does not invoke any non-trivial functions and, if x is an object, ex is an element of the set of potential results of an expression e, where either the lvalue-to-rvalue conversion is applied to e, or e is a discarded-value expression. ...

Since m is a constant expression, it is not odr-used and therefore does not need to be captured.

It appears that clangs behaviour is not compliant with the standard.

The first one actually works, try it out here: ideone.com/o8WIO1
I believe this is ok, see the quote from the standard. How do you see it?
@Beginner that quote actually confirms my answer. "shall" imposes a restriction on the program. It means that the variable must be captured. Since it was not captured (neither explicitly, nor implicitly by the use of default-capture), the program violates that rule.
Automatic variables from the reaching scope which are constant expressions, do not need to be captured
@M.M that is interesting. Can you find the rule that says so?

Collectives™ on Stack Overflow

Why is a const variable sometimes not required to be captured in a lambda?

3 Answers 3

4 Comments

5 Comments

9 Comments

Linked

Hot Network Questions