Здравствуйте, Великий Мессия, Вы писали:

S>>Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.

ВМ>сеть не нужна
ВМ>мутексы не нужны
ВМ>треиды не нужны
ВМ>контейнеры не нужны
ВМ>строки не нужны
ВМ>атомики не нужны

Великий Мессия тоже не нужен, из-за тупости.

В стандартной библиотеке должны быть т.н. vocabulary types, вроде строк, контейнеров, атомиков.

Но вот даже к тредам в стандартной библиотеке уже есть вопросы. Например, как ограничить размер стека для нового треда? Как менять приоритет для треда?

С++ -- это такой специфический язык, который сейчас нужен далеко не везде, а там, где он еще нужен, требуется контроль и, зачастую, прямая интеграция с возможностями конкретной платформы. Это уже даже на уровне std::thread видно. А в библиотеке для работы с сетью такой специфики будет еще больше.

Кроме того, для программирования на С++ нужны и другие вещи. Например, средства для работы с аргументами командной строки. Или средства для логирования. Или самые простые средства для криптографии (чтобы можно было хотя бы sha1 или sha512). И что, все это теперь тянуть в стандарт?

ВМ>сеть нужна

Далеко не всегда и далеко не всем.

ВМ>ее просили как минимум в опросах комитета которые проходят каждый год

В свое время очень многим был нужен XML.
А вообще, вспоминается (емнип) Генри Форд, который сказал: "Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь."

ВМ>нужно удобное подключение уже существующих библиотек — ага
ВМ>что бы каждый мог подключить свою шикарную реализацию строк

В проекте у текущего заказчика, как бы это не было смешно, используется три типа обычных векторов: std::vector, folly::fbvector и еще один самописный, потому что стандартный не подошел под специфический сценарий.

Проект стартовал в 2024-го без какого-либо легаси, тем не менее в него по разным причинам пришлось затащить и другие типы векторов, и другие типы ассоциативных контейнеров, т.к. классы из stdlib не тянули в конкретных условиях.

Повторюсь, C++ -- это сейчас очень специфический язык. Если кому-то нужно наговнякать без оглядки на скорость/ресурсоемкость/предсказуемость, то есть куча более безопасных языков с жирными стандартными библиотеками.

ВМ>и нужно было их внедрять Страуструпу еще на начальном этапе

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

ВМ>вместе с рефлексией и концептами

Ага, все это в 1985-ом году, когда Страуструп еще сам не знал как у него в языке будут шаблоны выглядеть.

ВМ>тогда бы возможно не появился раст а Вандервуд не изобретал lang D

Язык D изобрел Вальтер Брайт.

ВМ>Вандервуд обкатал эту идею в своем lang D

В D модули гораздо более вменяемые: https://dlang.org/spec/module.html

ВМ>и он был насколько я помню инициатором пропозла про модули

Насколько я помню, изначально было два предложения -- одно от Microsoft, второе от Google.
И делалось каждое предложение под то, кому как удобнее свои кодовые базы переводить под модули -- у Microsoft-а было свое представление о прекрасном, у Google -- свое.
А потом, когда в комитете ни одно из них не смогло победить, решили скрестить бульдога с носорогом.

S>>- внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.

ВМ>в синтаксис модулей? это асбурд

Повторюсь, Великий Мессия -- идиот.

ВМ>модули не заменяют а дополняют

Модули вводят новый контекст, в котором код гарантированно будет соответстовать C++20.
Т.е. как только в исходнике появляется "шапка" с ключевым словом "module", так сразу становится понятно, что код ниже адаптирован под C++20.
Что принципиально отличает модули от произвольных .hpp/cpp-файлов, в которых может быть код еще до C++98 времен.

А раз так, то можно в декларацию модуля тем или иным образом добавить "эпоху".

Это дело, емнип, даже комитетом обсуждалось. Но, к сожалению, не было принято. Экзекуторы же и сеть нужнее, ага.

ВМ>не нравится пишите без модулей

Так и делаю. И планирую в продолжать в ближайшие пару лет.

ВМ>а то тогда и в обычные файлы нужна эпоха, что бы можно было отказываться от сишечки

В обычные файлы это добавлять сложнее.

S>>Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.

ВМ>тяжело консерваторам, понимаю

Не понимаете. И не консерваторам, а тем, кто не любит искуственной сложности на ровном месте.

ВМ>но почему вы только здесь решили об этом рассказать?

Я об этом рассказываю везде (например).

ВМ>вот не смотря на то что мне не нравится ни сеть которую приняли, ни экзекуторы
ВМ>это лучше чем ничего

А у меня обратная точка зрения: чем говно, да еще в говняной упаковке (это я сейчас в первую очередь про модули), так лучше ничего.

ВМ>возьмите в кавычки "классный С++26"

Как и ожидалось, никаких рассказов про "классный C++26" не было.

ВМ>имелось ввиду что на лоре я не замечал от вас какой то критики по С++, скорее наоборот
ВМ>а последние ваши ответы там были про С++26 и точно не о его критике

В C++ много хорошего. Например, концепты и operator<=>. За это комитету огромное спасибо.
А если кто-то чего-то про C++ не знает, или не понимает, то почему бы не поделиться своими скудными знаниями.
Или развенчать какие-то мифы.

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