lambda 中值捕获的 std::move() 上的 decltype() 导致类型不正确

Question

It seems like there either is something wrong with Clang (9.0.0) or my understanding of how decltype() is specified to work in the standard. With reference to the following code,

#include <utility>
#include <string>

template <typename...> class WhichType;

template <typename T>
std::remove_reference_t<T>&& move_v2(T&& t) {
    WhichType<std::remove_reference_t<T>&&>{};
    return static_cast<std::remove_reference_t<T>&&>(t);
}

int main() {
    auto x = std::string{"a"};
    [v = x]() { 
        // move_v2(v);
        // WhichType<decltype(move_v2(v))>{};
        WhichType<decltype(std::move(v))>{};
    }();
}

The code above has the compiler output implicit instantiation of undefined template 'WhichType<std::__1::basic_string<char> &&>' instead of the expected const std::__1::basic_string<char> && in the template parameters of WhichType . Using move_v2 or WhichType in move_v2 itself seems to output the correct thing though.

However, Clang also seems to do overload resolution on the std::move(v) expression as I expected https://wandbox.org/permlink/Nv7yXnCbqxjJMVvX . This makes some of my worries go away, but I still don't understand the behavior of decltype() inside the lambda.

GCC does not seem to have this inconsistency in this particular case https://wandbox.org/permlink/5mhrOzLn5XZO8LNB .

---

Could someone correct me if I'm wrong with my understading of decltype() or point me to the exact places where this bug manifests in clang? Seems a bit scary from first glance. This can cause problems when used in SFINAE or something similar.

Answer 1

I have done a bit of digging, and it seems to me that the answer is a bit more nuanced than some of the comments makes it seem.

First there is this answer to an earlier question . To quote the important part:

[C++11: 5.1.2/14]: An entity is captured by copy if it is implicitly captured and the capture-default is = or if it is explicitly captured with a capture that does not include an & . For each entity captured by copy, an unnamed non-static data member is declared in the closure type. The declaration order of these members is unspecified. The type of such a data member is the type of the corresponding captured entity if the entity is not a reference to an object, or the referenced type otherwise. [..]

Then there is this answer to another question . Again quote:

5 The closure type for a non-generic lambda-expression has a public inline function call operator [...] This function call operator or operator template is declared const (9.3.1) if and only if the lambda-expression's parameter-declaration-clause is not followed by mutable .

I then put this together in a small test:

#include <iostream>
using std::cout;
using std::endl;

void foo(const std::string&) {
    cout << "void foo(const std::string&)" << endl;
}

void foo(std::string&) {
    cout << "void (std::string&)" << endl;
}

struct klaf
{
    std::string b;

    void bla() const
    {
        cout << std::boolalpha << std::is_const<decltype(b)>::value << endl;
        foo(b);
    }
};

int main()
{
    klaf k;
    k.bla();

    std::string s;
    const std::string s2;
    auto lam = [=]() {
        cout << std::boolalpha << std::is_const<decltype(s)>::value << endl;
        foo(s);

        cout << std::boolalpha << std::is_const<decltype(s2)>::value << endl;
        foo(s2);
    };
    lam();
}

Which outpouts (and the outputs are the same in GCC, Clang, and MSVC):

false
void foo(const std::string&)
false
void foo(const std::string&)
true
void foo(const std::string&)

klaf::b is (obviously) not const , but since the klaf::bla function is const , then klaf::b is treated as const in the call to foo .

The same is true in lam where s is captured by value with a type of std::string . However, s2 has been declared as const std::string and that carries over to the type of the data member in the lambda.

In short: Capture by value in a lambda does not make the captured member itself const , but since operator() for the lambda is const , then the members are promoted to const in that function (unless the lambda is declared mutable).

EDIT:

Inspired by comment from @arnes I found a difference is GCC and Clang:

int main()
{
    int i = 12;
    auto lam = [=, ic = i]() {
        cout << std::boolalpha << std::is_const<decltype(i)>::value << endl;
        cout << std::boolalpha << std::is_const<decltype(ic)>::value << endl;
    };
    lam();
}

This produces false false in Clang, but false true in GCC. In other words, a capture with an initializer becomes const in GCC but not in Clang.

Answer 2

Clang is wrong. decltype(std::move(v)) should be const && because the cv-qualifier v (which is equivalent to this->v ) is the union of the cv-qualifiers of *this (which is const in the operator() of a non- mutable lambda) and v (which is none), so v is a const lvalue. Then, std::move converts to an xvalue of the corresponding type, so decltype should be const && .

decltype behaves specially when applied to an id-expression or a member access expression ( this->v ), but that's not the case here. std::move(v) is a complicated expression, so it is treated as an ordinary expression.