cpp-ru / ideas

Идеи по улучшению языка C++ для обсуждения
https://cpp-ru.github.io/proposals
Creative Commons Zero v1.0 Universal
89 stars 0 forks source link

Использовать вложенные библиотеки вместо std2. #212

Closed apolukhin closed 3 years ago

apolukhin commented 3 years ago

Перенос предложения: голоса +9, -1 Автор идеи: d-yaroshev

Посмотрел большую часть обсуждений про std2 на недавнем CppNow. Присутствующие в подавляющем большинстве были в той или иной степени за. Мне кажется что std2 является худшим решением чем использовать вложенные библиотеки (и мне не нравится писать цифру 2).

Есть несколько вещей которые хотят, когда говорят про std2.

До известной степени это не возможно. Мы не можем поправить std::max или std::partition в std2 и научить этому разработчиков. Если что и будет добавлять сложности языку так это дубликаты, которые радикально (или в очень тонких случаях - не знаю что хуже) отличаются в поведении.

Некоторые из таких изменений можно провернуть, но мне кажется лучше не в std2, в специальных namespace.

Например - small optimized vector вполне может жить в отдельном namespace ровно так же как и вектор с полиморфным аллокатором pmr. Мне кажется что std::vector<int, std::sml::allocator<16>> (мб алиас как с pmr, std::sml::vector<int, 16>) сильно менее проблатично для принятия чем std2::vector у которого правила инвалидации итераторов вдруг отличаются от std::vector.

Первый раз я услышал про std2 от Eric Niebler когда он рассказывал про ranges. Даже если действительно нельзя положить ranges просто в std из-за коллизий имен, преимущество std2 перед std::rng кажется сомнительным. В std уже есть примеры нескольких библиотек, решающих одну и туже задачу - C и C++ способы ввода/вывода например, так что это тоже не кажется очень уж страшным.

Тут на самом деле наверное самый большой бонус от std2 который можно было бы получить - маленькие изменения в интерфейсе, который улучшат ваш код но сломают компиляцию в нескольких местах, если их просто так включить. Например возможность навесить concepts на алгоритмы. Но подобные вещи можно делать так же внутри под библиотек. Например std::rng::sort(f, l) может накладывать более жесткие ограничения на f, l так как для пользователя понятно,что это отдельная библиотека, уоторая поставляется вместе со стандартом, но она при этом достаточно не зависима. Ну и в целом, насколько полезны такие поломки.

В std очень много имен, которые друг с другом конфликтуют и мешаются. Но с std2 мы скоро окажемся ровно в той же ситуации.

Еще добавлю, что библиотеки в целом приятнее версионировать чем std, потому что в основном их использование локализировано. Переходить на filesystem2 или rng2 в каких-то отдельных кусочках, кажется легче и вполне может делаться по мере необходимости.

Вывод: Для того чтобы добавлять новые библиотеки не обязательно добавлять std2. Для избежания коллизий имен можно вполне иметь вложенные в std namespace.

apolukhin commented 3 years ago

d-yaroshev, 1 августа 2017, 0:08 Еще подумал, что проблему улучшения интерфейсов можно решать делая deprecation старых.

Условно говоря, старый алгоритм/контейнер остается но либо перегрузкой либо внутри той же реализации.

При этом при переходе на новый стандарт компилятор будет выдавать предупреждение, что данная перегрузка алгоритма/ версия контейнера является deprectaed. Если у пользователей -Werror, то они будут получать ошибку компиляции и большую часть преимуществ Concepts. В противном случае, у них будет переходный период в который будут вычищаться warnings (которые по прежнему будут нести в себе четкую информацию об ошибке),

h4tred, 3 августа 2017, 4:51 d-yaroshev, выбор реализации вполне можно организовать при помощи inline namespace. Со строками уже так сделано, по крайней мере в GCC: читать про Dual ABI.

d-yaroshev, 6 августа 2017, 14:24 h4tred, тоже может быть решением, но только для чего-нибудь легко диагностируемого, как более строгих интерфейсов. Изменения, которые могут повлиять на корректность внесут много проблем.

У нас был подобный опыт с частичным переездом с set/map на flat_set/flat_map - приходится много вручную проверять.

Евгений Власов, 29 сентября 2017, 15:19 При работе с boost меня всегда сильно раздражали вложенные namespace типа

boost::asio::serial_port_base::character_size charSize;
boost::asio::serial_port_base::stop_bits stopBit;
boost::asio::serial_port_base::parity pariy;
boost::asio::serial_port_base::flow_control flowControl;
boost::asio::io_service io;

Да конечно можно обложиться кучей typedef и using но это жутко не удобно.

yndx-antoshkka, 13 ноября 2017, 12:47 Комитет решил уходить от использования вложных namespace http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0816r0.pdf