[prog.c++.fantasy] Даешь по два стандарта в год!

Отдельная боль для меня в последние годы -- это возврат C++ к ситуации, которая была с первым стандартом в конце 1990-х: стандарт вышел, а компиляторов, которые бы его поддерживали, пришлось ждать несколько лет. А пока этого не случилось приходилось оглядываться на то, что есть в конкретном компиляторе.

С C++11 эта история повторилась. Но вот с C++14 и C++17 все было уже гораздо, гораздо лучше. И я уже, честно сказать, привык к хорошему: вышел новый стандарт и в свежих версиях компиляторов "большой тройки" он уже практически весь поддержан.

Однако, C++20 вернул нас в старые и недобрые времена. Уже середина 2024-го года, а полностью и нормально C++20 вроде как нигде и не реализован.

Что в этом плохого лично для меня?

Для того, чтобы освоить новую фичу (те же концепты или модули) нужно приобрести опыт. Поэтому сперва нужно дождаться, пока новая фича появится в компиляторе, затем нужно набить шишки при попытках ее использовать, потом наконец-то понять как и где эта фича должна применяться, чтобы было хорошо и не было больно.

Это все время. Чем дольше приходится ждать поддержки очередного стандарта, тем больше уходит этого самого времени 🙁

До сих пор придерживался мнения, что комитету по стандартизации C++ нужно было бы снизить темп. Например, перейти к выпуску новых стандартов не раз в три года, а раз в пять лет.

Но, боюсь, в современном мире это уже невозможно. Да и комитет выбрал для себя модель, когда в работе находится сразу куча предложений, а в час "Ч" в очередной стандарт просто включаются те предложения, которые сочли достаточно готовыми для этого. В рамках такой модели нет смысла увеличивать интервалы между стандартами.

В связи с этим мне подумалось: а почему бы не сократить интервал между стандартами, скажем, до полугода?

Не, реально.

Вот есть N предложений в работе. Какая-то часть из уже готова к включению в стандарт и просто ждет, пока же придет время фиксации этого стандарта. Так зачем ждать год-полтора-два, если уже есть готовые предложения? Давайте фиксировать по два стандарта в год. Например, весной -- C++24.1, осенью -- C++24.2. На следующий год весной будет C++25.1, а затем, осенью 2025-го, C++25.2 и т.д.

Как по мне, так хуже не станет.

Большие фичи, вроде модулей из C++20, могут (и будут) реализовываться годами. В 2024-ом году для меня нет разницы не реализованы ли модули из C++20 или же из C++23.2. Все равно же не реализованы.

Зато какая-нибудь мелкая фича, типа std::start_lifetime_as могла бы стать доступной для разработчиков в гипотетическом C++22.1, а не в С++23. Или вот в C++26 обещают добавить возможность обращаться к элементам parameter pack прямо по индексу. Так зачем ждать C++26, если можно включить ее в C++24.2?

Возможно, процесс стандартизации ISO сам по себе неторопливый и не может в принципе обеспечить принятие двух стандартов в год. Но лично у меня есть большие сомнения в том, что сейчас для C++ эта самая стандартизация ISO все еще важна.

Да, комитет по развитию C++ нужен. Спецификации языка, выпускаемые этим комитетом, нужны.

Но вот нужен ли на этих самых спецификациях штамп "ISO"? Сильно сомневаюсь. Возможно, в 1990-е развитие в рамках ISO имело смысл. Сейчас же его сложно разглядеть. А посему можно и задаться вопросом: а стоит ли сейчас цепляться за существующую модель стандартизации C++ или же выгоднее ее пересмотреть?

[prog.c++] Первые краткие впечатления от C++20

С конца прошлого года принимаю участие в проекте, который использует некоторые фичи C++20 и, местами, даже что-то из C++23. Сам я С++20 применяю мало, но некоторые первые впечатления от "самого современного C++" появились так что попробую ими поделиться, тезисно, без погружения.

spaceship operator. "Дайте два!" После того, как попробуешь, просто не хочется возвращаться на C++17.

designated initializers. Отличная штука для простых структур с двумя-тремя полями.

std::span "изкаропки". Очень удобно.

ranges. Использовать приходилось немного и нечасто. Прикола, что называется, не понял. Практически во всех моих случаях можно было бы тоже самое записывать и на старых алгоритмах с итераторами. Ну и как-то на старых алгоритмах все это записывается у меня пока быстрее, чем на ranges -- с итераторами понятно и привычно, а с ranges пока выкуришь описание с cppreference, пока прикинешь что и с чем комбинировать... 🙁

concepts. Написал пару-тройку своих концептов, несколько раз описал секцию requires с использованием концептов из стандартной библиотеки. Не могу сказать, что слишком уж проникся. Но как способ лучше задокументировать код шаблонов -- очень даже OK, гораздо лучше, чем выписывать ожидания от параметра шаблона в комментариях к шаблону.

Что уже не понравилось в концептах, так это то, что их нужно описывать на уровне пространства имен. У меня были случаи, когда хотелось концепт описать внутри класса. Что-то типа:

class class_with_complex_logic {
  concept MyRequirement = ...;

  template<MyRequirement Param>
  void do_something(Param && param) {...}

  template<MyRequirement Param>
  void do_something_else(Param && param) {...}
  ...
};