C++17 изменения вывода auto при фигурной инициализации

[xandox]

auto x1 = { 1, 2 }; // ошибка: невозможно наличие нескольких элементов при фигурной инициализации auto

В обще-то x1 будет std::initializer_list, что бы случилась ошибка, должно быть

auto x{1, 2};

[sborisov]

Смотрите Proof — это ссылка на стандарт.

auto x1 = { 1, 2 }; // error: cannot have multiple elements in a braced-init-list with auto

[xandox]

Да, я уже посмотрел, но похоже там ошибка
во-первых вот тут по другому http://en.cppreference.com/w/cpp/language/template_argument_deduction#Other_contexts, ну или по ссылке ошибка.
во-вторых — это странно, таким образом получается intitializer_list никак не создать.

[sborisov]

Никакой ошибки нет ни там ни там.
Т.к. объект только создаётся в обоих случаях будет вызван конструктор.
Эти варианты эквиваленты и сгенерируют абсолютно одинаковый ассемблерный код.

auto x{1, 2};
auto x1 = { 1, 2 };

[xandox]

В 11/14 — да, это одно и тоже, но суть прделожения которое в статье описывается как раз в том, что бы сделать их разными. КМК
Если второй вариант будет давать ошибку, то и такой код должен давать ошибку

for (auto x: {1, 2, 3}) { }

[sborisov]

11/14 тут непричём. Я же написал:

Т.к. объект только создаётся в обоих случаях будет вызван конструктор

[xandox]

Я же написал:

Т.к. объект только создаётся в обоих случаях будет вызван конструктор

Все верно, только нужно понять конструктор какого типа?
И так как второй вариант это не прямая инициализация, то логично было бы создавать initializer_list, как и во всех остальных случаях.

[sborisov]

В статье написано, что нужно сделать одинаковым

auto x = 1; 
auto x{1};

[saluev]

Кажется, что между стандартом и cppreference.com приоритет за стандартом.

[xandox]

ну ок, вот ссылка на предложение
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html
там в примерах то же самое написано.

[sborisov]

получается intitializer_list никак не создать.

Cоздавайте на здоровье

auto x = std::initializer_list<int>{1,2,3};

[xandox]

Ну так да, но в таком случаи и можно без auto и = вообще обойтись. Но не об этом же речь.

[xandox]

А, я понял в чем проблема, у нас ссылки на разные предложения. В одном так, в другом эдок. Понятно теперь.
Я опирался на ту которая на clang.llvm.org. и cppreference похоже ту да же смотрит.

[xandox]

Как не странно, но сайте gcc ссылка на тот же предложение что и у clang
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html

В общем все правильно написано на cppreference, а у вас в статье ссылка на старое предложение которое изменилось.

[sborisov]

Спасибо! Поправил статью.

[VadimVP]

Proof по ссылке это не стандарт, а очень старая версия предложения.
То что попало в стандарт (см. свежую версию черновика) совпадает с cppreference.

[sborisov]

Спасибо! Поправил статью.

[Antervis]

значит, ошибка в компиляторе

[lookid]

#define auto do{ raise(SIGSEGV); }while(0);

Я пофиксил.

[Antervis]

Отставить панику! Смотрим стандарт, 7.1.7.4.1:

auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
auto x2 = { 1, 2.0 }; // error: cannot deduce element type
auto x3{ 1, 2 }; // error: not a single element
auto x4 = { 3 }; // decltype(x4) is std::initializer_list<int>
auto x5{ 3 }; // decltype(x5) is int

Поменялись только пункты 3 и 5. Инициализация списка как в варианте 1 осталась.

Proof

Глупо использовать в качестве пруфа ссылку на документ 13-ого года

[sborisov]

Да, я уже обновил статью и ссылки. Спасибо.

[equeim]

auto x{foo()}; // x = initializer_list<int>

Странно, у меня при компиляции с C++11 (GCC 6.3.1) это все равно int.

А вообще, что им мешало сделать так:

auto foo { 1 }; // int
auto foo { { 1 } }; std::initializer_list<int>

Заодно это решило бы проблему невозможности в некоторых случаях вызова конструктора копирования при использовании универсальной™ инициализации.