Feature freeze C++20. Приняли ли Coroutines и Modules?

На днях прошла встреча международного комитета по стандартизации C++ в американском городе Кона. Это была не просто встреча, а feature freeze! Никакие серьёзные новые идеи больше не могут просачиваться в стандарт, остаётся лишь пара встреч на добавление предварительно одобренных вещей, исправление недочётов и устранение шероховатостей.

Всё это и многое другое ожидает вас под катом. Ожидать ли Модули и Корутины в C++20, будет ли там быстрая библиотека для форматирования вывода, сможет ли она работать с календарями, добавили ли std::stacktrace, начнёт ли компилятор сам вызывать std::move в ряде случаев, приняли ли std::flat_map?

Coroutines TS

Самые жаркие дебаты разгорелись вокруг сопрограмм. Комитету предстояло рассмотреть три различных подхода к сопрограммам и решить, принимать в стандарт имеющиеся Coroutines TS, либо идти другим путём.

Выбор был не простой, у каждого подхода есть свои минусы и плюсы:

• N4775:
  • + нет ограничений на то, что сопрограммы должны быть описаны в заголовочном файле
  • − нет строгих гарантий, что не произойдёт динамическая аллокация
  • ± не самый простой интерфейс (P1477R0 это исправляет)
  • − страшненькие ключевые слова co_await и co_yield (предложение P1485R0 от РГ21 это исправляет)
  • + 3 года применяются на практике

• P1063R2:
  • + нет динамических аллокаций
  • − сопрограммы должны быть описаны в заголовочном файле или самим надо хитровыкручиваться с type erasure
  • − ещё более страшные ключевые operator[<-] и [->]
  • − нет рабочего прототипа
  • − не самый простой интерфейс для создания асинхронных вещей

• P1430R0:
  • + нет динамических аллокаций
  • − сопрограммы должны быть описаны в заголовочном файле или самим надо хитро выкручиваться с type erasure
  • + нет страшных ключевых слов, всё гладенько
  • + пользователи корутин не видят страшных корутиновых внутренностей (даже не видят co_await аналогов, всё из коробки работает)
  • − первое предложение, ни разу не обсуждалось, требует кучи доработок
  • − невозможно реализовать на текущих технологиях (требуют поддержки структур динамического размера), требуют огромных трудозатрат для реализации
  • ± немного напоминают лапшу из callback

После долгих дебатов сопрограммы были приняты в C++20 в том виде, в котором они были в Coroutines TS (с co_* префиксами и старыми точками кастомизации).

Modules

На обсуждение модулей повлиял один интересный документ с замерами производительности:
P1441R0. Трактовать результаты можно по разному: от «существующие системы сборки и реализация модулей ещё недостаточно оптимизированы» до «модули плохо масштабируются с ростом сложности проекта».

В итоге, спустя 15 лет обсуждения, прототипирования и экспериментов с внедрениями, модули были приняты в C++20. Помимо этого документа, комитет обсудил ряд небольших правок к текущим модулям.

Format

Good news everyone! В C++20 можно будет безопасно и очень быстро форматировать строки. Скажите «до свидания» std::ios, std::locale и прочим ужасам 90-х! Теперь Python подобный синтаксис для форматирования доступен из коробки в С++: P0645R5.

Если не найдут фатальных недостатков в подгруппе Library, то теперь и даты можно будет выводить по-человечески! Более того, было принято предложение на интеграцию нового форматирования и календарных времён P1361R0.

Networking, Executors и Properties

Executors являются важным кирпичиком для поддержки Networking в C++ из коробки. Для Executors нужны Properties — возможность модифицировать тип данных, в зависимости от параметра переданного на этапе компиляции, не меняя концепт типа.

Не смотря на то, что текста для включения в стандарт всего пара страничек, предложение вызвало бурные обсуждения. Properties описаны в P1393R0. Предложение позволяет делать практически всесильные точки кастомизации, менять поведение любых функций, использующих Properties.

В итоге решено было Properties включать в язык только в C++23, а соответственно и Executors, и Networking в C++20 не появятся.

Прочее

В черновик C++20 уже были внесены следующие изменения:

• Структуры без конструкторов (агрегаты) теперь можно инициализировать, используя круглые скобки P0960. На практике это значит, что теперь std::make_shared, std::make_unique, std::*::emplace* будут корректно работать с агрегатами без ошибок компиляции
• Были добавлены функции lerp для линейной интерполяции P0811
• Добавлена возможность векторизировать алгоритмы стандартной библиотеки P1001
• Методы std::span теперь возвращают беззнаковые типы (по аналогии со всей стандартной библиотекой) + была добавлена функция std::ssize для получения размера контейнера в виде знакогового числа P1227
• Unordered контейнеры научились искать значения, используя заранее посчитанный хеш P0920

Много других вещей ожидают финального ревью в подгруппах Library и Core, для включения в C++20:

• Эффективное ожидание на std::atomic; классы семафоров и барьеров P1135
• std::flat_map P0429
• std::flat_set P1222
• std::function_ref P0792
• constexpr для <cmath> и <cstdlib> P0533
• std::ranges::to<любой-контейнер> для сохранения диапазона значений в контейнер P0533
• Возможность эффективно извлекать строки из std::*stringstream и передавать во владение пользовательские строки P0408
• Множественные правки для operator<=>, ranges, constexpr

Заслуги РГ21

В самый первый день за горячо любимое в Яндекс.Такси предложение на Stacktrace P0881R3 взялась подгруппа Core. Замечания по дизайну были дополнительно обсуждены в подгруппе LEWG, ещё раз проработаны в Core. В итоге в течении всей недели вносились правки и велись обсуждения. В черновик стандарта предложение ещё не включено, но должно оказаться в C++20 (если не найдут вдруг какой-то фатальный недостаток).

До обсуждения нашей идеи P1485R0 на приведение ключевых слов для корутин дело не дошло.

Нас попросили перепроверить, что предложенное API позволяет избежать reader contention. Также в SG1 Concurrency обсуждали идею concurrent unordered map P1485R0. Также сказали поисследовать concurrent unordered контейнеры, которые не имеют функции erase и не защищают значение контейнера от конкурентной модификации.

Комитет порекомендовал оставить специализации только для std::pair, std::tuple, std::array и std::basic_string от пользовательских аллокаторов. Предложение от ZaMaZaN4iK на специализацию std::hash для различных классов стандартной библиотеки P1406R0 решено было сильно порезать.

Предложение позволяет специализировать два шаблона, получить полный набор математических операций и сравнений для всех новых типов. В подгруппе цифр SG6 обсудили механизм для взаимодействия различных новых классов чисел P0880R2. По итогам обсуждения решили попробовать расширить механизм, чтобы им можно было пользоваться не только для нужд стандартной библиотеки, но и пользователи могли использовать эти операторы для своих типов.

Также обсуждали наши незначительные предложения, включая feature testing macro P1424R0 и политики на их добавление в стандарт.

Нам сказали продолжать работу в этом направлении и накидали примеров, которые не должны ломаться с новыми правилами. Быстро обсудили нашу идею, позволяющую компилятору убирать лишние копирования R0889R1.

Вместо итогов

C++20 будет так же разительно отличаться от C++17, как С++11 отличался от C++03. Огромное количество новых технологий и новых парадигм: Concepts, Contracts, Ranges, Modules, Coroutines, constexpr контейнеры и constexpr динамический полиморфизм, «ниблойды» и т. д.

Поэтому, если у вас есть какая-то боль или вы не согласны с каким-то нововведением, пожалуйста, оставляйте свои мысли на этой странице. В скором времени мы, Рабочая Группа 21, отправим комментарии к черновику стандарта C++20.

Если вы хотите что-то изменить в C++ или предложить свою идею, то всегда можете написать на https://stdcpp.ru/, где люди из РГ21 помогут вам донести ваши желания до комитета. Следующее собрание международного комитета будет летом, на нём могут начать рассматривать нововведения для C++23.

Скоро состоится открытая встреча РГ21, следите за анонсами на events.yandex.ru. Желаете поговорить с нами вживую? Так же ищите нас на апрельской конференции C++ Russia в Москве.