Помилка під час використання в класі ініціалізації нестатичного члена даних та конструктора вкладеного класу

Наступний код досить тривіальний, і я очікував, що він повинен скомпілюватись добре.

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

    B b;

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

Я протестував цей код за допомогою g ++ версії 4.7.2, 4.8.1, clang ++ 3.2 та 3.3. Окрім того, що g ++ 4.7.2 здійснює сегментацію цього коду ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57770 ), інші перевірені компілятори видають повідомлення про помилки, які мало що пояснюють.

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 і 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())
                    ^

Зробити цей код компілювальним можливо, і, здається, він не повинен мати ніякої різниці. Є два варіанти:

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

або

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

Цей код насправді неправильний чи компілятори помиляються?

Цей код насправді неправильний чи компілятори помиляються?

Ну, ні. Стандарт має дефект - він говорить і про те, що Aвважається завершеним під час розбору ініціалізатора для B::i, і про те, B::B()(що використовує ініціалізатор для B::i), можна використовувати у визначенні A. Це явно циклічно. Розглянемо це:

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

Це протиріччя: B::B()неявно noexceptтоді і тільки тоді A()не залишити, і A()не кидайте тоді і тільки тоді B::B()це НЕ noexcept . У цій галузі існує ряд інших циклів та суперечностей.

Це відстежується за основними проблемами 1360 та 1397 . Зауважте, зокрема, цю примітку в основному випуску 1397:

Можливо, найкращим способом вирішення цього було б зробити неправильно сформовану для нестатичного ініціалізатора даних даних використання конструктора за замовчуванням для свого класу.

Це особливий випадок правила, яке я застосував у Clang для вирішення цієї проблеми. Правило Кланга полягає в тому, що конструктор за замовчуванням за замовчуванням для класу не може використовуватися до синтаксичного аналізу нестатичних ініціалізаторів даних для цього класу. Отже, Клан видає тут діагностику:

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

... тому що Clang аналізує аргументи за замовчуванням перед тим, як він аналізує ініціалізатори за замовчуванням, і для цього аргументу за Bзамовчуванням потрібно буде проаналізувати ініціатори за замовчуванням (для неявного визначення B::B()).

Можливо, це проблема:

§12.1 5. Конструктор за замовчуванням, який за замовчуванням не визначений як видалений, неявно визначається, коли його підтримують (3.2) для створення об’єкта типу свого класу (1.8) або коли він явно за замовчуванням після першого оголошення

Отже, конструктор за замовчуванням генерується при першому пошуку, але пошук не вдасться, оскільки A не повністю визначений, і B всередині A не буде знайдено.