27
votes

I would want to use a constexpr value in a lambda. Reading the answer to Using lambda captured constexpr value as an array dimension, I assumed the following should work:

  #include<array>
  int main()
  { 
    constexpr int i = 0;
    auto f = []{  
      std::array<int, i> a;
    };
    return 0;
  }

However, Clang 3.8 (with std=c++14) complains that

variable 'i' cannot be implicitly captured in a lambda with no capture-default specified

Should this be considered a bug in clang 3.8?

BTW:

The above code does compile with gcc 4.9.2. If I change the lambda expresion to capture explicitly:

...
auto f = [i]{
...

clang 3.8 compiles it, but gcc 4.9.2 fails:

error: the value of ‘i’ is not usable in a constant expression ...

1
does [constexpr int _i =i]{} does any difference?David Haim
Nope, that does not compile under gcc 4.9.2, nor Clang 3.8.Olaf Booij
hmmm.... I supposed you thought about #define as a (temprary) solution?David Haim
but macros are evil! And plus, they can't be assigned with constexpr function.Guillaume Racicot
@GuillaumeRacicot: That's just a mantra. quoting from here: stackoverflow.com/questions/14041453/… "Macros are just like any other tool - a hammer used in a murder is not evil because it's a hammer. It is evil in the way the person uses it in that way. If you want to hammer in nails, a hammer is a perfect tool."Karoly Horvath

1 Answers

12
votes

Should this be considered a bug in clang 3.8?

Yep. A capture is only needed if [expr.prim.lambda]/12 mandates so:

enter image description here

Note in particular the highlighted example. f(x) does not necessitate x to be captured, because it isn't odr-used (overload resolution selects the overload with the object parameter). The same argumentation applies to your code - [basic.def.odr]/3:

A variable x whose name appears as a potentially-evaluated expression ex is odr-used by ex unless applying the lvalue-to-rvalue conversion (4.1) to x yields a constant expression (5.20) that does not invoke any non-trivial functions…

This requirement is certainly met.

…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 (4.1) is applied to e, or e is a discarded-value expression (Clause 5).

i is its set of potential results as per [basic.def.odr]/(2.1), and the l-t-r conversion is indeed immediately applied as its passed to a non-type template parameter of object type.

Hence, as we have shown that (12.1) isn't applicable - and (12.2) clearly isn't, either - Clang is wrong in rejecting your snippet.