Создатель C++ впервые за 36 лет выступил против консенсуса комитета

Это хорошо написанное и весьма дипломатичное резюме от Херба Саттера. Я недостаточно в курсе, чтобы быть уверенным, что он прав в том, что оппозиция Страуструпа была главной причиной провала голосования по C++26 там, где другие прошли, но это звучит правдоподобно.

Там также перечислены 6 возможных путей вперёд для C++26 с плюсами и минусами. Я думаю, они примерно такие:

A. Пропустить официальный стандарт C++26, но включить эти функции в C++29.

B. Убрать контракты из C++26 и принять его.

C. Сказать «пожалуйста» и проголосовать снова.

D. Подправить контракты в части виртуальных функций и проголосовать снова.

E. Принять C++26 как национальные стандарты многих разных стран, а не как международный стандарт.

F. Сделать E, а также рассмотреть выход из ISO и переход в ANSI/INCITS.

Я думаю, это придаёт слишком большое значение этому событию и позиции Бьярне по контрактам.

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

Игнорировать этот исторический контекст при анализе голосования кажется ошибкой.

Я давно особо не следил за C++ (последняя классная фича, которую я видел, — это концепты). Обычно мне нравится тот странный выразительный код-гольф, который можно писать с новыми фичами. Например, я попробовал использовать концепты, чтобы гарантировать совместимость размерностей матрицы с желаемой операцией. Не то чтобы очень полезно, но был занятный мысленный эксперимент.

Но эти предлагаемые контракты... Я просто не вижу особой выгоды по сравнению с явным написанием собственных утверждений.

Полагаю, можно увидеть требования в объявлениях, но я готов поспорить, что навороченные современные объявления C++ быстро становятся настолько длинными и многословными, что от их чтения быстро устанешь. Возможно, в эпоху LLM они полезнее?

Как человек, который потратил несколько недель, пытаясь вникнуть в C++ (до эпохи LLM, так что, может, сейчас лучше?), и в итоге просто сдался от путаницы, я действительно нашёл сложным разбираться с множеством разных способов сделать что-то. Ну, какой указатель мне использовать? Как мне итерироваться? Уверен, на это есть ответ, но мне просто было легче вернуться к python и обратиться к rust, когда нужно.

Похоже, часть проблемы в том, что функция должна быть выпущена правильно с первого раза, потому что она будет жить вечно. Может, разрешить объявлять функции устаревшими, а затем удалять их, могло бы помочь?

Но не знаю, я не писал ничего, что жило бы 36 лет, так что, может, текущий подход — к лучшему!

Просто зашёл сказать, что Саттер не только прав, повторяя здесь позицию Бьярне, но он также автор, на мой взгляд, самой влиятельной статьи о прогрессе производительности оборудования и переходе к параллельному исполнению: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf

36 лет устойчивого согласия — это нехорошо; это значит, что никто ничего не отвергает, и у вас огромный грязный снежный ком катится с горы.

Уверен, я не единственный, но мне кажется, что C++ конец/всё. Я работаю в кодовой базе на C++ и занимаюсь C++ более 20 лет, и, по крайней мере для меня, письмена на стене уже видны.

1. C++ небезопасен. Бьярне продолжает выступать с речами, которые по сути говорят: «используйте его идеально и не делайте ошибок, и он безопасен». Это больше не работает. В мире, где LLM могут найти любую ошибку для эксплуатации, все проекты на C++ изо всех сил пытаются не отставать, и сохранение их на C++ практически гарантирует, что в будущем будет больше эксплойтов. Да, не каждая ошибка решается переходом на более безопасный язык, но сокращение поверхности атаки в новой реальности больше нельзя откладывать.

2. LLM могут переписать. Раньше аргумент был такой: «есть унаследованные кодовые базы на C++, так что C++ никогда не умрёт». Это был веский аргумент до того, как LLM просто перепишет всё. Понимаю, люди скажут, что они не идеальны, но и люди тоже. К тому же они всё время становятся лучше, и мы видим их прогресс. Люди направляют LLM на какой-то проект, и он волшебным образом заставляет его работать на какой-то другой платформе и т.д. Ясно, что это происходит.