decltype for lambda capture gives wrong type

[apolukhin]

Bugzilla Link	38325
Version	trunk
OS	Linux
CC	@apolukhin,@dwblaikie,@egorpugin,@zygoloid

Extended Description

According to my reading of the http://eel.is/c++draft/expr.prim.id.unqual#2 the following code should compile:

#include <type_traits>
#include

constexpr std::true_type is_const(int const &) { return {}; }
constexpr std::false_type is_const(int &) { return {}; }

int main() {
int x = 0;
[y = x, x] {
const int z = 0;
assert(is_const(x)); // OK
assert(is_const(y)); // OK
assert(is_const(z)); // OK

static_assert(!decltype(is_const(x))::value, "");
static_assert(decltype(is_const(y))::value, ""); // Fails (OK on GCC)
static_assert(decltype(is_const(z))::value, "");

static_assert(!std::is_const<decltype(x)>::value, "");
static_assert(std::is_const<decltype(y)>::value, ""); // Fails (OK on GCC)
static_assert(std::is_const<decltype(z)>::value, "");

} ();
}

However, two lines marked with "Fails (OK on GCC)" do not pass the asserts.

[zygoloid]

I don't agree. Per [expr.prim.id.unqual]p2, the type of 'x' or 'y' within the lambda is the type of a class member access expression naming the corresponding capture. Those members are of type (non-const) int, but the lambda's *this parameter is const-qualified, so the correct behavior would be:

static_assert(decltype(is_const(x))::value, "");
static_assert(decltype(is_const(y))::value, "");
static_assert(decltype(is_const(z))::value, "");

static_assert(!std::is_const<decltype(x)>::value, "");
static_assert(!std::is_const<decltype(y)>::value, "");
static_assert(std::is_const<decltype(z)>::value, "");

decltype(x) is decltype((lambda).x), which is the type of the member, which is int.
decltype(is_const(x)) doesn't match the special case decltype(id-expression) pattern, so it gives the type of the expression, which doesn't care whether 'x' occurs in an unevaluated operand.

Now, this changed in P0588R1, which clang does not yet implement. Prior to that, the lambda transformation was not applied in unevaluated operands, meaning that 'x' and 'y' were both non-const inside the decltype, and Clang's current behavior is correct in that model.

Note in particular that [y = x] behaves as if a variable

auto y = x;

is declared outside the lambda and then captured (see [expr.prim.lambda.capture]p6), so any difference in behavior between the x and y cases is a bug (in GCC in this case).

We can certainly keep this open to track the fact that clang doesn't implement P0588R1 yet, but that's already tracked on the cxx_status page (or it would be, if our website ever updated to match svn).

[cor3ntin]

Per Richard's comment not a bug, and we already track P0588 in multiple places