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

Какой есть стандарт разрешите поинтересоваться ? Как раз манглинг между компиляторами не стандартизирован ... Я еше помню как Стауструпа спросили когда коммитет займется ABi на что он схватился за голову и стал объяснять как сложно заставить договориться раные компании насчет общего ABI и это будет сделано не скоро )

да, манглинг у мелкомягкого компилятора явным образом отличается от gcc'шного в линуксах например.

Это отдельгый стандарт ItaniumAbi  https://github.com/itanium-cxx-abi/cxx-abi

Там кстати забавно почитать их баги, можно поужасаться неоптимальностям в самых фундаментальных вещах

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

но непосредственно к языку это отношения все же не имеет.

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

В той же репе можно посмотреть основных контрибьюторов. 90% имён совпадут с Core группой c++

Так что ломающие ABI изменения не пройдут Core

Хорошо бы, очень упростит жизнь. А то пока на известную статью "std::visit is everything wrong with modern C++" очень сложно возражать по существу.

А в этом плане да, платформенный низкоуровневый ABI стандартизирован ... Я имеел ввиду нету обещого ABi в С++ между различными компиляторами ... Тот же манглинг не стандартизирован и нельзя скомпилировать библиотеку одним компилятором и использовать другим если это только не gcc и clang

а сильно ли упростит жизнь? ну, то есть жили же без этого и неплохо жили. мне кажется, что фича несколько переоценена. тем более для языка, где она не поставлена во главу угла как first class citizen, вот в каком-нибудь хаскеле она в ядре языка и все вокруг этого строится. в плюсах - не так.

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

то есть да, можно будет сделать пару докладов где сказать: смотрите, код на С++, а выглядит будто бы Ocaml!

но я не уверен что с этого реальные программы на С++ станут надежней, читабельней, проще и быстрее.

не каждая фича, которая очень хороша в языке A, будет столь же хороша если её втащить в язык B.

а втаскивание новых фич в язык - это необратимо и ОЧЕНЬ дорого.

Понятно, что это более-менее синтактический сахар, а не что-то прорывное. Но как по мне это примерно настолько же упростит жизнь при работе с вариантами, как лямбды в С++11 упростили работу с алгоритмами из STL. До одиннадцатых плюсов многие предпочитали написать for просто потому, что так короче и читаемей.

дык, после C++11 я вообще только for пишу 🙂 он же теперь новый, и удобный. std::for_each больше нафиг не нужен

Некоторые ещё пишут std::rotate 😉

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

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

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

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

Субъективно я бы предпочёл поддержку алгебраических типов данных из коробки разным вещам типа consteval и контрактам. Но это, конечно, дело вкуса.

Я вообще за то, чтобы всё, что можно реализовать библиотеками, было библиотеками. Но очевидно, что тут библиотечного решения так и не предложили. Костыли вроде overloaded_t для работы с std::visit ужасны, такие кишки не должны торчать наружу.

паттерн матчинг тесно связан с деструкцией (которая structural binding in c++) которая в с++ в абсолютно зачаточном состоянии. плюс, по хорошему, это же должно применяться и на уровне вызовов функций. плюс, следуя идеологии С++, все это должно применяться и быть кастомизируемым для любых пользовательских типов.

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