company_banner

Черновик FAQ: Почему стандарты С++ выходят каждые три года?

Автор оригинала: Herb Sutter
  • Перевод

У WG21 есть строгий график (см. P1000) выпуска стандарта каждые три года. И никаких задержек.

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

Всё это я расписал в виде вопросов и ответов для следующего черновика Р1000, и разослал копию участникам комитета, направлявшимся в Кёльн. Этот материал будет опубликован в следующей публичной версии Р1000, её мы разошлём через несколько недель начиная с текущего момента.

Однако и черновик FAQ может быть интересен публике, поэтому предлагаю вашему вниманию его копию. Надеюсь, он будет для вас по большей части полезен, в чём-то просветит, и, возможно, даже немного развлечёт.


В стандарте есть баги, следует ли вам отложить C++20?


Конечно да, и нет.

Мы движемся в заданном направлении с выбранной скоростью: исправление багов запланировано на этот последний год, поэтому в графике в раннем С++ «19» (Kona) установлен крайний срок прекращения добавления функциональности (feature freeze) в С++ «20», чтобы у нас был год на исправление багов, включая работу с комментариями из разных стран этим летом. До начала 2020-го (встречи в Кёльне, Белфасте и Праге) мы должны дать обратную связь и применить любые другие решения проблем, а также исправления багов.

Если провести ещё одну-две встречи, то можно было бы добавить <название_фичи>, которая почти готова, так что следует ли вам отложить C++20?


Конечно да, и нет.

Подождите, когда пройдёт ещё пара встреч (после Праги), и С++23 будет открыт для бизнеса, и в первую очередь проголосуем за добавление <название_фичи> в рабочий черновик С++23. Так мы поступили с концептами: они не были готовы к переходу из TS прямо в С++17. Поэтому на первой встрече по С++20 (в Торонто) проголосовали за перенос основной функциональности концептов в черновик С++20, что дало много времени на совершенствование и доработку остальной противоречивой части TS (не-«шаблонный» синтаксис), которая была внедрена в следующем году (Сан-Диего). Теперь вся функциональность готова.

Кажется, это слишком строго. Зачем выпускать релизы IS через фиксированные интервалы (три года)?


Потому что в случае с релизом С++ IS это один из двух основных вариантов управления проектом, и опыт показывает, что этот вариант лучше второго.

Какие два варианта управления проектом для релиза С++ IS?


Рад, что вы спросили.

В случае с релизом есть два основных варианта: выбрать фичи или срок релиза, и когда выбираешь одно, то теряешь контроль над определением другого. Нельзя одновременно контролировать и то, и другое. Вкратце:

Если мы будем контролировать это
Мы перестанем контролировать это
Мы можем работать над «большими» многолетними фичами?
Когда мы добавляем фичи в рабочий черновик IS?
Что мы делаем, если обнаруживаем проблемы с добавленной фичей?
«Что»: фичи, которые мы отгружаем
«Когда»: срок релиза.
Да, в документах с предложениями и рабочем черновике IS.
Обычно раньше, чтобы провести больше интеграционных тестов → снижается средняя стабильность рабочего черновика.
Задерживаем выпуск стандарта.
«Когда»: срок релиза
«Что»: фичи, которые мы отгружаем
Да, в документах с предложениями и «ветках фич» в TS.
Обычно позже, когда фича лучше проработана → повышается средняя стабильность рабочего черновика.
Убираем фичу, позже можем добавить её снова, если она готова к моменту отправления следующего «поезда» IS.

Поясняю:

(1) «Что»: выбираем фичи и отгружаем по мере готовности, не нужно выбирать время релиза. Если выясняется, что нужно больше времени на доработку фичи из черновика стандарта, то всему миру придётся тебя ждать. Ты работаешь над большими фичами, которые требуют нескольких лет разработки, а потом пытаешься вообще перестать работать над новыми фичами, пока стабилизируешь релиз.

Так было с C++98 (его ждали примерно в 1994-м, Бьёрн сказал, что если релиз не выйдет к тому времени, это будет провалом) с C++11 (его назвали 0x, потому что x ждали к 2007-му). Это подход «оставляем пациента не зашитым» на неопределённый срок, который привёл к задержке интеграционного тестирования и релиза. А это, в свою очередь, привело к большой неуверенности на рынке относительно сроков выхода следующего стандарта, да и выйдет ли он вообще (да, не только участники разработки, но даже некоторые члены комитета серьёзно сомневались в 1996-м и 2009-м, появятся ли вообще соответствующие релизы). В течение нескольких лет большинство компиляторов не соответствовали стандарту, потому что никто не знал, сколько несовместимых изменений выкатит комитет в новом релизе, или когда его вообще ждать? Это привело к большому разнообразию и фрагментации поддержки С++ в компиляторах, доступных для сообщества.

Почему мы так поступили, мы что, идиоты? Не совсем, просто были неопытны и… скажем так, «оптимистичны». Это была дорога, вымощенная лучшими намерениями. В 1994-1996-м и в 2007-2009-м мы действительно верили, что сейчас передвинем ещё на одну-две-три встречи, и всё сделаем, и каждый раз переносили на сроки до четырёх лет. И теперь на своём опыте убедились, что не может быть переноса на год или два.

К счастью, всё изменилось благодаря варианту (2).

(2) «Когда»: выбираем срок релиза и отгружаем те фичи, что будут готовы, не нужно выбирать набор фич. Если выясняется, что нужно больше времени на доработку фичи из черновика стандарта, мы её выбрасываем и отгружаем то, что готово. Можно продолжать работать над большими фичами, на создание которых уходит времени как на несколько релизов, но делать это в сторонних «ветках», добавляя их в мастер-ветку IS по мере готовности. И ты постоянно работаешь над фичами, потому что их разработка полностью отделена от текущего релиза (нет большой точки соединения).

Этого подхода мы придерживаемся с 2012-го и не хотим от него отказываться. Это подход «регулярно зашиваем пациента», который приводит к ожиданию более высокого качества благодаря принудительным регулярным интеграциям и отказу от добавления работы в черновик IS, пока она не достигнет определённого уровня стабильности, обычно в рамках ветки фичи. Также это создаёт предсказуемый цикл релиза, на который может опираться рынок. За эти годы авторы компиляторов стали всё раньше и раньше после очередного релиза выпускать соответствующие стандарту версии своих продуктов, чего раньше никогда не было. А в 2020-м мы ожидаем выхода полностью соответствующих стандарту реализаций в один год с выходом стандарта, чего тоже никогда раньше не было. Это только во благо для всего рынка — разработчиков, пользователей, преподавателей.

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

Насколько серьёзно вы относитесь к подходу (2)? Если по мнению авторитетного члена комитета какая-то большая фича будет «почти готова», то у вас возникнет соблазн немного подождать, верно?


Очень серьёзно относимся, и нет.

У нас есть статистика: в 2016-м в Джексонвилле, когда мы окончательно определялись с фичами для С++17, Бьёрн Страуструп выступил на пленарном заседании с предложением включить концепты в С++17. Когда консенсуса не достигли, Страуструпа прямо спросили, хочет ли он задержать релиз С++17 на год, чтобы включить в него концепты. Бьёрн без колебаний и увёрток ответил «нет», и добавил, что С++17 без концептов важнее, чем С++18 или С++19 с концептами, хотя Страуструп работал над ними около 15 лет. Выбор стоял такой: (2) выпускаем С++17 без концептов, а затем С++20 с концептами (что мы и сделали), или (1) переименовываем С++17 в С++20, что изоморфно (2) за исключением пропуска С++17 и отказа от выпуска того, что уже было готово для С++17.

А что насчёт компромисса между (1) и (2)? Скажем, обычно придерживаемся (2), но с «небольшой» гибкостью в сроках, чтобы получить «немного» дополнительного времени, если нужно доработать фичу?


Нет, потому что получится (1).

Фред Брукс в The Mythical Man-Month популярно объяснил про «мифический маленький перенос» и пришёл к заключению: «Не допускайте никаких маленьких переносов».

Представьте, что мы перенесли С++20. Нам пришлось бы вернуться от (2) к (1), вне зависимости от того, как сильно мы стараемся избежать этого, и при этом не получили бы никаких выгод. Если бы мы решили отложить С++20, чтобы отполировать его, то мы задержали бы стандарт минимум на два года. Не бывает таких понятий, как перенос одной или трёх встреч, потому что за это время другие продолжат (справедливо) говорить: «ну, моей фиче нужно всего ещё одну встречу, мы же всё равно перенесли, давайте ещё одну перенесём». И если мы переносим как минимум на два года, то это означает, что С++20 становится С++22, а вероятнее всего С++23… но мы уже собираемся отгружать С++23! — То есть в любом случае мы будем отгружать С++23, и разница лишь в том, что мы не переносим С++20 с большим объёмом проделанной работы, готовой к релизу, и не заставляем весь мир ждать ещё три года. Задержка не пойдёт на пользу этим фичам, большинству из них или всем вместе.

Поэтому предложение равносильно «давайте превратим С++20 в С++22 или С++23», и простой ответ на него: «да, у нас будет и С++23, но в дополнение к С++20, а не вместо него». Задержка С++20 означает пропуск С++20 вместо выпуска хорошего, стабильного, готового продукта, и никакой пользы от этого не будет.

Но фича X сломана / нужно больше времени, чем у нас осталось на исправление багов в C++20!


Не вопрос! Мы её можем просто выпилить.

В этом случае кому-то нужно будет написать в EWG или LEWG (в зависимости от ситуации) письмо с описанием ситуации, и предложить удалить фичу из рабочего черновика IS. Эти группы рассмотрят обращение, и если они решат, что фича сломана (и пленум с ними согласится), то фичу отложат до следующего релиза С++. Мы уже поступали так с концептами С++0х.

Но в случае с (1) мы перенесём не только эту фичу, а весь набор фич из С++20 в С++23! Это был бы… перебор.

Подход (2) означает «основные/второстепенные» релизы?


Нет. Сначала мы так говорили, пока не поняли, что (2) всего лишь означает, что не нужно выбирать набор фич даже с точки зрения «основного/второстепенного» релиза.

Подход (2) означает лишь «отгружаем то, что готово». Релизы получаются:

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

C++14 и C++17 были относительно маленькими, потому что много усилий по стандартизации тратилось на долгоиграющие фичи, описанные в предложениях к внедрению (например, контракты) и «ветки фич» в TS (например, концепты).

C++20 — это большой релиз…


Да. В C++20 много крупных фич. Три из крупнейших начинаются на «ко» (концепты, контракты, корутины), так что мы могли бы назвать его co_cpp20. Или co_dependent.

…и не слишком ли много сделано за трёхлетний цикл для C++20?


Нет, см. выше «раз на раз не приходится».

C++20 большой не потому, что за три года мы сделали больше, а потому что много долгих разработок (включая как минимум две, над которыми в текущем виде мы работали с 2012-го в виде P-предложений и TS-«веток») дошли до стадии готовности и их решили включить в черновик IS одного и того же релиза.

Практически всегда основные фичи разрабатываются по много лет. Главная разница между подходом (1) для С++98 и С++11 и подходом (2) заключается в том, что в С++98 и С++11 задерживали выпуск до готовности всех этих фич, а теперь мы отгружаем большие по мере готовности, и попутно с ними релизим многое другое.

С++20 прошёл через такой же трёхлетний цикл, как С++14 и С++17. Мы не сделали за последние три года больше, чем за два предыдущих цикла, просто допилили больше основных фич. Если бы какая-то из них не была готова, то мы бы её выкинули и доделывали уже для С++23. Если так произойдёт, мы сообщим об этом в предложении по внедрению и объясним причины.

С++14+17+20 составили наш третий девятилетний цикл (2011-2020) после С++98 (1989-1998) и С++11 (2002-2011). Но поскольку мы придерживались подхода (2), то также выпустили наработки, которые были готовы к окончанию трёхлетнего и шестилетнего циклов.

Не лучше ли вылавливать баги, когда продукт находится в разработке, а не после того, как он выпущен?


Конечно лучше.

Но если мы говорим о причинах задержки выхода стандарта С++, то этот вопрос подразумевает два ложных предположения:

  • что до выхода стандарта фичи не выходили и не использовались (по многим уже есть опыт использования в production);
  • и что все фичи можно использовать вместе до выхода стандарта (нельзя).

Поясняю:

  1. Большинство крупных фич С++20 были реализованы в том виде, в каком они отражены в текущем черновике стандарта, как минимум в одном компиляторе, и в большинстве случаев уже использовались в production-коде (то есть уже доступны для пользователей, которые очень довольны). Например, корутины (внедрённые всего за пять месяцев до этой статьи) два года применялись в production в MSVC и год в Clang, чему оказались очень рады крупные клиенты (например Azure и Facebook).
  2. Мы не собираемся вылавливать многие проблемы взаимодействия фич, пока пользователи не начнут использовать их в production, то есть до выхода стандарта, потому что многие разработчики будут ждать его выхода, чтобы реализовать разные проекты. И если мы проявим неуверенность в отношении сроков релиза, то эти реализации тоже будут отложены. Ну, что-то всё-таки реализуют, но многое будет поставлено на паузу, пока разработчики не будут уверены, что мы готовы релизить. Спросите создателей <название_любимого_компилятора>, что произошло, когда они реализовали <название_крупной_фичи> до того, как она появилась в опубликованном стандарте. Во многих случаях реализовывать приходится неоднократно, и обламывать потребителей тоже неоднократно. Поэтому разработчики предпочитают ждать, когда комитет утвердит те или иные фичи.

Наконец, не забывайте и о проблеме взаимодействия фич. Мы не только выпускаем их тогда, когда готовы, после этого нам ещё нужно время на поиск проблем взаимодействия между фичами и на добавление поддержки таких взаимодействий, о которых мы просто не можем узнать до того, как новые фичи станут широко использовать. И не имеет значения, насколько мы задержим релиз стандарта, всегда будут взаимодействия, которые мы сможем исследовать лишь гораздо позже. Управлять таким риском нужно с помощью гибкого проектирования, обеспечивающего совместимость фич, а не ждать избавления от всех рисков.

Стандарт никогда не будет идеальным… разве вы не релизите ошибки?


Да.

Если мы видим, что фича не готова, то мы должны её удалить из релиза.

Если мы видим, что фича может быть лучше, и знаем, что изменение может оказаться обратно-совместимым, то это не причина отказываться сейчас от её релиза. Её можно выпустить как расширение в следующем С++.

Мы намеренно выпускаем фичи, которые планируем улучшать в будущем, пока уверены в том, что можем соблюсти обратную совместимость.

Но не следует ли вам стараться минимизировать ошибки в релизах?


Да. Мы стараемся.

Но мы не стараемся избежать всех рисков. Также существует риск и (возможная) цена отказа от выпуска того, что нам кажется готовым. И чаще всего мы оказываемся правы.

Вы уверены, что сейчас качество лучше, чем при использовании подхода (1)?


Да.

Согласно объективным метрикам, объёму комментариев из разных стран и отчётов об ошибках, С++14 и С++17 были нашими самыми стабильными релизами, и по этим метрикам они в 3-4 раза превзошли С++98 и С++11. А причина именно в регулярности релизов, в размещении больших фич сначала в TS-ветки (включая полные описания их интеграции с основным стандартом) и в их последующем вливании, когда мы убеждаемся в готовности.

С 2012-го основной стандарт всегда поддерживается в состоянии почти-готов-к-отгрузке (так что даже рабочие черновики такого же высокого качества, как релизы стандартов С++98 и С++11). Такого никогда не было ранее, когда мы долгое время держали пациента не зашитым, с длинными списками проблем и разложенными вокруг органами, которые мы собираемся скоро засунуть обратно. Теперь мы знаем, что можем выдерживать график с высоким качеством работы, потому что всегда остаёмся в состоянии близкой готовности к релизу. Если бы хотели, то могли бы выпустить CD хоть сейчас, без встречи в Кёльне, и всё равно качество было бы гораздо выше, чем когда-либо у CD C++98 или С++11 (по правде, и их опубликованных стандартов). А учитывая, что С++98 и С++11 были успешны, то понимание, что сейчас качество ещё выше, означает, что мы на верном пути.

C++98 и C++11 разрабатывались примерно по 9 лет и были очень хорошими продуктами…


Да: 1989-1998 и 2002-2011.

…а C++14 и C++17 были второстепенными релизами. C++20 является основным релизом?


Повторюсь, я считаю, что правильно сравнивать С++14+17+20 как единое целое: это наш девятилетний цикл, но поскольку мы придерживались подхода (2), мы также выпустили и те наработки, которые были готовы к завершению трёхлетнего и шестилетнего циклов.

Подход (2) позволяет достигать feature-based целей вроде P0592 для следующего C++?


Конечно! Пока в нём нет слов вроде «должен включать в себя эти фичи», потому что тогда это будет подход (1).

Стремиться к определенному набору фич и отдавать одним из них приоритет — это нормально, но тогда это вопрос приоритетности. Пока что мы будем брать только то, что готово, но мы можем выбирать, над чем работать в первую очередь, чтобы подготовить как можно скорее.
Mail.ru Group
1 014,24
Строим Интернет
Поделиться публикацией

Похожие публикации

Комментарии 26

    +4

    У подхода (2) есть один очевидный плюс — на меня не вываливают фактически новый язык "в один день".


    Между С++98 и С++11 просто пропасть, как синтаксическая, так и по содержанию стандартной библиотеки. Эта же пропасть есть между С++11 и С++20. Если бы на меня вывалили всё то, что появилось в С++14 и С++17 вдобавок к тому, что появится в С++20, я бы наверное ушел программировать на другом языке.

      +2
      Тем не менее стоит признать, что C++20 будет «сырым» — в том же смысле в каком C++11 был «сырым».

      Очень многие фичи в нём недовылизаны… и это нормально. Потому что ну невозможно боььшие, «тяжёлые» фичи «вылизать в лаборатории».

      У вас выбор:
      1. Выпустить C++20, услышать поток матерной брани от людей, которые попытаются воспользоваться фичами в продакшн… и исправить C++23 так, чтобы он не был таким «сырым».
      2. Потратить три года, вылизать фичи ещё — и всё равно получить «сырой» C++20… только теперь он будет называться C++23.

      Почему так происходит? Потому что без использования на реальных проектах в миллионы строк никто не может выловить всех косяков… а их, в свою очередь, не делают с фичами, которые не в стандарте.
        0

        Не могу похвастаться глубоким знанием стандарта. Скажите, ведь новые стандарты обратно совместимы с предыдущими? И, если да, то какая-то косячная фича в будущем может быть только расширена, дополнена итп, но не переделана?

          0
          Может быть и выпилена auto_ptr was fully removed in C++17. Если я правильно понял вопрос.
            0
            Вы, может быть удивитесь, но ответа на этот вопрос нет. Сейчас ситуация очень странная:
            1. Де-юре никаких ограничений по совместимости у комитета по стандартизации нет.
            2. Де-факто предложение что-то поломать — встречается требованием объяснить кто именно будет затронут и жуткой паникой.
            В C++20 «выпилили» несколько фич официально, и хотят посмотреть — что будет. А перед C++20 уже будут решать — то ли официально вносить «совместимость» как одну из целей, то ли, наоборот — начать принимать изменения, которые могут на неё повлиять…
          0
          если следить за развитием языка (даже статей на хабре хватит), то вы заметите, что многие фичи получают огласку за 5-6 лет до их включения в стандарт
            0

            Есть один момент — если эти фичи не стандартизованы, то использовать их на продакшене зачастую довольно рискованно. Представим себе, что даже какая-нибудь небольшая вещь вроде std::optional вдруг внезапно поменяет свой интерфейс, а вы уже 7 лет пишете с её использованием в ожидание того, что она войдет в стандарт такой, какая она есть.

              0
              Есть и обратная тенденция: фичи, которые комитет по стандартизации включил в драфт, часто разрешают применять даже если формально релиза ещё не было. У нас сейчас активно используются designated initializers и начинают использоваться модули — хотя «де-юре» они появятся в C++20.

              А вот пока в черновиках их не было — они были запрещены.
                0
                и начинают использоваться модули

                Шел 2019 год. Мда…
                  0
                  Даже не знаю как на это реагировать… Слишком рано или слишком поздно?

                  Хочу напомнить что модули были включены в стандарт буквально несколько месяцев назад, уже-таки в 2019м, до этого никто точно не знал — будут они в C++20 или нет, а если будут — то в каком виде.

                  И если вы любите использовать фичи, которых в стандарте ещё нет, а потом всё 20 раз переделывать… то это не значит, что другие компании (особенно крупные) должны вести себя так же…
                    0
                    И если вы любите использовать фичи, которых в стандарте ещё нет

                    Мы не любим использовать фичи, которых в стандарте ещё нет.
                    Но вопрос очевидно давно назрел.
                    В итоге, спустя 15 лет обсуждения

                    Это просто. Ну я не знаю как — семантика приличного языка не позволяет.
                      0
                      Слишком рано или слишком поздно?

                      Без обид, но слишком опоздали.
                      Ну вот, #include изобрели в 1968, он устарел в 1969, и далее вы примерно на полвека опоздали.
                        0
                        Здаётся мне что #include изобрели таки пораньше. А язык C — это 1972й-1973й. И в нём никаких модулей до сих пор нету.
                    0
                    и начинают использоваться модули

                    О, раз вы их как-то более-менее опробовали в бою.


                    А зачем вообще модули? Я почитал, подумал и не понял, чем они мне (ну и людям вроде меня) помогут.


                    Единственное, что меня не устраивает в препроцессоре и #include — скорость компиляции. Но то, как устроены темплейты в C++, означает, что полноценной раздельной компиляции шаблонов не будет никогда, что для того кода, который я обычно пишу, означает, что модули сэкономят максимум на повторном парсинге хедеров (и то не факт), что, опять же, для того кода, который я обычно пишу, не так много.


                    Я слышал, людям они ещё нравятся потому, что макросы там не утекают, всякое такое. Но, опять же, в коде, который я пишу, и в библиотеках, которыми я пользуюсь, они почему-то и так не утекают (отчасти потому, что их толком нет, а то, что есть, утекать должно).


                    А вот designated initializers да, тема, я как узнал, что их в стандарт включат, начал везде пихать.

                      0
                      Я слышал, людям они ещё нравятся потому, что макросы там не утекают, всякое такое.
                      Не только макросы. Ничего не утекает. Главное преимущество — то, что если ваш модуль использует какой-нибудь <set>, то это не значит, автоматически, что его получат и те, кто ваш модуль захочет поиспользовать. И, соответственно, ничего не развалится, когда вы <set> прекратите использовать.

                      А время компиляции — да, тут большого выигрыша нет, это не о том.
                        0
                        А время компиляции — да, тут большого выигрыша нет, это не о том.

                        гм, что-то мне казалось, что выигрыш в скорости сборки — это основной аргумент в пользу модулей.

                          0
                          Эту проблему давным-давно решили precompiled headers. Вряд ли модули смогут что-то лучше сделать.

                          Нет, модули — это о другом. Решение проблем с ODR и инкапсуляция. Нет, какое-то ускорение будет, да, но ради него — никто не стал бы весь этот огород городить…
                            +1
                            Эту проблему давным-давно решили precompiled headers. Вряд ли модули смогут что-то лучше сделать.

                            разве модули не обещали в среднем двукратный прирост скорости компиляции?
                              0
                              Уж не знаю какую некромагию вы применяли чтобы услышать мнение модулей о чём-либо… или вы о каких-то шарлатанах, которые мало чего понимают в С++ и его проблемах говорите?

                              Если о последнем — то явки, пароли, в студию. Откуда могло бы взяться какое-то существенное ускорение — мне, например, неясно. И кто вам его обешал — мне неизвестно тоже.
              +1
              Пусть икается тем (ладно-ладно, только Гору Нишанову ;-)), кто решил использовать co_async/co_yield в качестве зарезервированных слов для coroutines. Ну почему не async/yield, как во всех других языках? Ведь были же достойные альтернативы (от того же самого Christopher Kohlhoff — автора библиотеки Boost.Asio), но Microsoft как обычно продавила своё решение…
                0

                Может быть слишком много кода бы сломалось c async/yield? Никто ведь не хочет переписывать тонны кода на плюсах просто так.

                  0
                  Могу сказать, что в пыхе тоже много умных сделали свой yield, и он у них ожидаемо сломался, когда это внезапно стало ключевым словом. Ничего, переписали.
                    0
                    Не знаю, кто такая «пыха», но в PHP ломают совместимость местами не то, что в минорных релизах, но даже и в «мелких фиксах» — это не повод теперь такую же фигню в нормальных языках устраивать…
                    0

                    Решить проблему можно было очень просто — ввести слова asyng и await в список зарезервированных, скажем в С++14 и кидать варнинги 6 лет подряд. Думаю за это время все всё переписали бы.

                    0
                    кто решил использовать co_async/co_yield в качестве зарезервированных слов для coroutines. Ну почему не async/yield, как во всех других языках?

                    есть такая функция, std::this_thread::yield(). C P1485 были бы и слова нормальные, и сигнатура, но сначала дотянули, а потом стало слишком поздно. Хотя про то что co_* уродливо, орало всё комьюнити, с самого первого дня. Плюс, мы имеем UB с перепутанными return/co_return на абсолютно ровном месте.

                    Теперь единственный вариант — реализовать P1485 во всех основных компиляторах в виде расширения и продвигать в с++23. Одно маленькое «но» — msvc проприетарный.
                    +2
                    (картинка про antoshkka отдельно доставила)

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое