Устаревший лямбда-захват в C ++ 20

Question

Как предлагается в документе P0409R2

Я ожидаю, что определение x будет исключено из C ++ 20 и не будет скомпилировано, но, похоже, оно работает в g ​​++ (GCC) 8.1.0. Кто-нибудь знает, если я что-то не так делаю?

В Visual Studio 2017 происходит сбой компилятора с ошибкой вокруг определения y. ошибка C3791: «это» не может быть явно записано, когда режим захвата по умолчанию - копия (=)

Живой код

#include <iostream>

struct  X {
    void  f()
    {
        int  value = 3;

        auto  x = [=] {         // Deprecated from C++20: 
            return  value + g(); 
        };

        auto  y = [=, this] {   // Recommended method from C++20: 
            return  value + g();  // [=] The this pointer will not be captured, so capture with specifying this 
        };
    }

    int g() const
    {
        return  2;
    }
};

int  main()
{
    X().f();
}

Answer 1

Предложение не означает принятие. Тем не менее, читая формулировку и пример, он заявляет:

 [=, this]{ };      // OK, equivalent to [=]

Что, по-видимому, указывает на то, что x разрешено. Я также не вижу явного упоминания об этом как об устаревшем. Он даже упоминает обратное:

Мы не будем рассматривать амортизацию в следующем обзоре, поскольку мы заинтересованы только в изучении долгосрочного направления, а амортизация без направления не так уж интересна.

Answer 2

Прежде всего, это просто предложение, оно не означает, что оно автоматически станет частью стандарта. Во-вторых, C ++ 20 все еще находится в разработке.

Теперь, даже если предложение было принято в C ++ 20 и даже если компиляторы его реализовали, оно прямо говорит, что не предлагает устаревший способ:

Мы не будем рассматривать амортизацию в следующем опросе, так как мы заинтересованы только в изучении долгосрочного направления и амортизации без направления не все так интересно.

Хорошо, похоже, в C ++ 20 это действительно будет устаревшим. Но опять же, поскольку стандарт C ++ 20 еще не окончательный, компиляторы реализуют его по ходу, поэтому gcc еще не реализовал это.

Что касается VS, похоже, что в версии 2017 года не реализован захват C ++ 17 по этому значению.