Comments 26
У подхода (2) есть один очевидный плюс — на меня не вываливают фактически новый язык "в один день".
Между С++98 и С++11 просто пропасть, как синтаксическая, так и по содержанию стандартной библиотеки. Эта же пропасть есть между С++11 и С++20. Если бы на меня вывалили всё то, что появилось в С++14 и С++17 вдобавок к тому, что появится в С++20, я бы наверное ушел программировать на другом языке.
Очень многие фичи в нём недовылизаны… и это нормально. Потому что ну невозможно боььшие, «тяжёлые» фичи «вылизать в лаборатории».
У вас выбор:
1. Выпустить C++20, услышать поток матерной брани от людей, которые попытаются воспользоваться фичами в продакшн… и исправить C++23 так, чтобы он не был таким «сырым».
2. Потратить три года, вылизать фичи ещё — и всё равно получить «сырой» C++20… только теперь он будет называться C++23.
Почему так происходит? Потому что без использования на реальных проектах в миллионы строк никто не может выловить всех косяков… а их, в свою очередь, не делают с фичами, которые не в стандарте.
Не могу похвастаться глубоким знанием стандарта. Скажите, ведь новые стандарты обратно совместимы с предыдущими? И, если да, то какая-то косячная фича в будущем может быть только расширена, дополнена итп, но не переделана?
1. Де-юре никаких ограничений по совместимости у комитета по стандартизации нет.
2. Де-факто предложение что-то поломать — встречается требованием объяснить кто именно будет затронут и жуткой паникой.
В C++20 «выпилили» несколько фич официально, и хотят посмотреть — что будет. А перед C++20 уже будут решать — то ли официально вносить «совместимость» как одну из целей, то ли, наоборот — начать принимать изменения, которые могут на неё повлиять…
Есть один момент — если эти фичи не стандартизованы, то использовать их на продакшене зачастую довольно рискованно. Представим себе, что даже какая-нибудь небольшая вещь вроде std::optional вдруг внезапно поменяет свой интерфейс, а вы уже 7 лет пишете с её использованием в ожидание того, что она войдет в стандарт такой, какая она есть.
А вот пока в черновиках их не было — они были запрещены.
и начинают использоваться модули
Шел 2019 год. Мда…
Хочу напомнить что модули были включены в стандарт буквально несколько месяцев назад, уже-таки в 2019м, до этого никто точно не знал — будут они в C++20 или нет, а если будут — то в каком виде.
И если вы любите использовать фичи, которых в стандарте ещё нет, а потом всё 20 раз переделывать… то это не значит, что другие компании (особенно крупные) должны вести себя так же…
И если вы любите использовать фичи, которых в стандарте ещё нет
Мы не любим использовать фичи, которых в стандарте ещё нет.
Но вопрос очевидно давно назрел.
В итоге, спустя 15 лет обсуждения
Это просто. Ну я не знаю как — семантика приличного языка не позволяет.
Слишком рано или слишком поздно?
Без обид, но слишком опоздали.
Ну вот, #include изобрели в 1968, он устарел в 1969, и далее вы примерно на полвека опоздали.
Я слышал, людям они ещё нравятся потому, что макросы там не утекают, всякое такое.Не только макросы. Ничего не утекает. Главное преимущество — то, что если ваш модуль использует какой-нибудь <set>, то это не значит, автоматически, что его получат и те, кто ваш модуль захочет поиспользовать. И, соответственно, ничего не развалится, когда вы <set> прекратите использовать.
А время компиляции — да, тут большого выигрыша нет, это не о том.
А время компиляции — да, тут большого выигрыша нет, это не о том.
гм, что-то мне казалось, что выигрыш в скорости сборки — это основной аргумент в пользу модулей.
Эту проблему давным-давно решили precompiled headers. Вряд ли модули смогут что-то лучше сделать.
разве модули не обещали в среднем двукратный прирост скорости компиляции?
Если о последнем — то явки, пароли, в студию. Откуда могло бы взяться какое-то существенное ускорение — мне, например, неясно. И кто вам его обешал — мне неизвестно тоже.
Решить проблему можно было очень просто — ввести слова asyng и await в список зарезервированных, скажем в С++14 и кидать варнинги 6 лет подряд. Думаю за это время все всё переписали бы.
кто решил использовать co_async/co_yield в качестве зарезервированных слов для coroutines. Ну почему не async/yield, как во всех других языках?
есть такая функция, std::this_thread::yield(). C P1485 были бы и слова нормальные, и сигнатура, но сначала дотянули, а потом стало слишком поздно. Хотя про то что co_* уродливо, орало всё комьюнити, с самого первого дня. Плюс, мы имеем UB с перепутанными return/co_return на абсолютно ровном месте.
Теперь единственный вариант — реализовать P1485 во всех основных компиляторах в виде расширения и продвигать в с++23. Одно маленькое «но» — msvc проприетарный.
Черновик FAQ: Почему стандарты С++ выходят каждые три года?