Erro ao usar a inicialização em classe de membro de dados não estáticos e construtor de classe aninhada

O código a seguir é bastante trivial e eu esperava que ele compilasse bem.

struct A
{
    struct B
    {
        int i = 0;
    };

    B b;

    A(const B& _b = B())
        : b(_b)
    {}
};

Testei este código com g ++ versão 4.7.2, 4.8.1, clang ++ 3.2 e 3.3. Além do fato de que g ++ 4.7.2 segfaults neste código ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57770 ), os outros compiladores testados fornecem mensagens de erro que não explicam muito.

g ++ 4.8.1:

test.cpp: In constructor ‘constexpr A::B::B()’:
test.cpp:3:12: error: constructor required before non-static data member for ‘A::B::i’ has been parsed
     struct B
            ^
test.cpp: At global scope:
test.cpp:11:23: note: synthesized method ‘constexpr A::B::B()’ first required here 
     A(const B& _b = B())
                       ^

clang ++ 3.2 e 3.3:

test.cpp:11:21: error: defaulted default constructor of 'B' cannot be used by non-static data member initializer which appears before end of class definition
    A(const B& _b = B())
                    ^

Tornar este código compilável é possível e parece que não deve fazer diferença. Existem duas opções:

struct B
{
    int i = 0;
    B(){} // using B()=default; works only for clang++
};

ou

struct B
{
    int i;
    B() : i(0) {} // classic c++98 initialization
};

Este código está realmente incorreto ou os compiladores estão errados?

Este código está realmente incorreto ou os compiladores estão errados?

Bem, nenhum. O padrão tem um defeito - ele diz que Aé considerado completo ao analisar o inicializador para B::ie aquele B::B()(que usa o inicializador para B::i) pode ser usado dentro da definição de A. Isso é claramente cíclico. Considere isto:

struct A {
  struct B {
    int i = (A(), 0);
  };
  A() noexcept(!noexcept(B()));
};

Isso tem uma contradição: B::B()é implicitamente noexceptiff A()não joga e A()não joga iff nãoB::B() é . Existem vários outros ciclos e contradições nesta área. noexcept

Isso é rastreado pelos problemas principais 1360 e 1397 . Observe, em particular, esta nota na edição principal 1397:

Talvez a melhor maneira de lidar com isso seja tornar malformado para um inicializador de membro de dados não estáticos usar um construtor padrão de sua classe.

Esse é um caso especial da regra que implementei no Clang para resolver esse problema. A regra de Clang é que um construtor padrão padronizado para uma classe não pode ser usado antes que os inicializadores de membros de dados não estáticos para essa classe sejam analisados. Portanto, o Clang emite um diagnóstico aqui:

    A(const B& _b = B())
                    ^

... porque o Clang analisa os argumentos padrão antes de analisar os inicializadores padrão, e este argumento padrão exigiria que Bos inicializadores padrão de já tivessem sido analisados ​​(a fim de definir implicitamente B::B()).

Talvez este seja o problema:

§12.1 5. Um construtor padrão que é padronizado e não definido como excluído é implicitamente definido quando é odr- usado (3.2) para criar um objeto de seu tipo de classe (1.8) ou quando é explicitamente padronizado após sua primeira declaração

Portanto, o construtor padrão é gerado quando consultado pela primeira vez, mas a pesquisa falhará porque A não está completamente definido e B dentro de A, portanto, não será encontrado.