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

d-yaroshev
d-yaroshev

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

- Breaking changes в поведении.

До известной степени это не возможно. Мы не можем поправить 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++ способы ввода/вывода например, так что это тоже не кажется очень уж страшным.

- Breaking changes в интерфейсе.

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

- Засилие имен в std.

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

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

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

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

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

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

У нас был подобный опыт с частичным переездом с set/map на flat_set/flat_map - приходится много вручную проверять.
d-yaroshev
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).