Или вы имеете в виду, что OuterFunc возвращает ссылку на локальную для OuterFunc переменную. В этом случае у меня для вас плохие новости - этот код всегда был UB, при том и в чистом C вы скорее всего получите проезд по стеку.
Потому что, если написать, как в первом примере выше, то можно легко напороться на ситуацию, когда неименованный временный TempObject из первого примера уничтожится, не доходя даже вовнутрь OuterFunc, т.к. его областью видимости почему-то являются круглые скобки, а не фигурные!
C++ так не работает, в данном примере временные объекты будут жить до окончания вызова функции OuterFunc.
А почему почему вы хотите это запрещать? Например многие проекты используют макрос, чтобы задать namespace и inline namespace с версией. С вашим предложением этот функционал перестанет работать
В данном случае никакой новый функционал не добавляется и основная задача предложения - это не сломать старое поведение мароксов в легаси коде (с их обработкой только в препроцессоре)
Но ведь макросы и так можно использовать в именованных модулях в global module fragment и они прорастают ниже в module unit, и за его пределы не экспортируются.
Так зачем делать работу, по обучению AST в макросы?
Приведите пожалуйста примеры, какой именно новый функционал получаем, с данным предложением. Да, заставить макросы работать по правилам C++ - это приятно, но слишком много нюансов и проблем возникает, пока кажется что овчинка не стоит выделки
#define MACRO_LOCAL macro_local
import mod; // В модуле mod видны оба макроса MACRO_GLOBAL и MACRO_LOCAL
никак не сможет работать с модулями. Именованный модуль уже "запечён", и в него ничего больше не прилетает. Такой модуль - это практически иммутабельный бинарный блоб. Что-то схожее предлагалось в https://github.com/cplusplus/papers/issues/2316 и комитет был против
После чего вот прям благодать настала со стандартами C++14 и C++17. Но вот уже с C++20 опять та же
С C++20 основная засада - модули. Остальное всё уже реализовано, но модули - очень большая и многогранная фича, требующая работы над множеством частей C++ (форнтенд и мидленд компилятора, линкеры, системы сборки, библиотеки, ...)
В С++23 и C++26 нет таких "монстров", так что должно всё гладко идти и вендоры быстро наверстают отставание
Оно уже распараллелено, насколько это возможно. Однако, есть критические секции, которые не паралеллятся или плохо паралеллятся
а так ли важна сейчас для C++ именно ISO стандартизация?
Как ни странно - да. C++ чуть ли не единственный современный язык программирования, который можно использовать в приложениях, напрямую влияющих на жизнь человека (самолёты, автомобили, медицинское оборудование, ...). А для такого использования нужна ISO стандартизация.
Без этого - потеряется ощутимая часть пользователей
Но не удивлюсь, если офлайн участники тоже не знают какая там погода - обычно времени на осмотр окресностей нет, график очень плотный, а в больших аудиториях с окнами зачастую напряжёнка
Какой вообще смысл в таких тусовках?
Основной смысл - общий сбор, точка синхронизации и формального голосования. Онлайн тоже есть, но встреча работает эффективнее
Выпуск стандарта ещё влечёт за собой накладные расходы - формальное создание особого черновика, сбор коментариев от стран, испраление замечаний, финализация стандарта в вышестоящих инстанциях ISO... Это достаточто ресурсоёмкие процессы
Пока кажется что 3 года - отличный баланс между скоростью выпуска новых фичей и уменьшением мороки для людей в комитете
какой смысл, если статья описывает то, что уже отлито в граните?
Ну, во первых, ещё не отлито. Во вторых, рефлексия уже лет 7 варится, времени повлиять у заинтресованных людей было предостаточно. В третьих, мало того что целая прорва постов была во множестве соц сетей, так и несколько рабочих прототипов на godbolt.
За эти годы рефлексия активно менялась под фидбеком пользователей. И менялись важные фундаментальные части: ушли от шаблонов к type erased meta::info, репортить ошибки стали через исключения и т.д.
И если самая большая проблема рефлексии, это необходимость использовать :вместо предпочитаемого вами@ - то всё сделано комитетом просто замечательно.
Но по факту решение принято за почти закрытыми дверьми, повлиять на него, кроме как участвуюя в работе комитета, у таких как я, нет возможности.
Вот именно! У вас есть возможность повлиять на результат. Но ведь высказывать "фи" намного проще, чем прорабатывать и продумывать идеи
у меня есть сомнения в том, что у комитета сейчас есть нормальная обратная связь с пользователями
Обратной связи много, но дельных мыслей и рабочих идей - крайне мало. Как правило связь вида "не программирую, но осуждаю" или "ну наконец, отлично!", или "мне не нравится синтаксис, вот вам другой сомнительный синтаксис".
Вот например у статьи уже набралось почти пол сотни комментариев. Есть ли средини них хоть пара, с которыми можно работать?
Ваше предложение по ссылке не позволяет получить информацию о том, позвали && функцию или const& функцию. Соответсвенно вы потеряли огромный кусок функционала, получив синтаксис не лучше чем с deducing this
Я затрудняюсь сейчас примомнить современный язык программирования без линтеров, guidelines и подобных инструментов. Вся индустрия больна?
А подскажите, как сделать лучше? Что упростить?
Или вы имеете в виду, что OuterFunc возвращает ссылку на локальную для OuterFunc переменную. В этом случае у меня для вас плохие новости - этот код всегда был UB, при том и в чистом C вы скорее всего получите проезд по стеку.
C++ так не работает, в данном примере временные объекты будут жить до окончания вызова функции OuterFunc.
Пока новостей нет. Работа идёт в https://wg21.link/p3286 , но там пока очень далеко до финала
А какие именно больные места?
Именно на публичный интерфейс и влияет макрос для namespace, так что сломается :(
А почему почему вы хотите это запрещать? Например многие проекты используют макрос, чтобы задать namespace и inline namespace с версией. С вашим предложением этот функционал перестанет работать
Но ведь макросы и так можно использовать в именованных модулях в global module fragment и они прорастают ниже в module unit, и за его пределы не экспортируются.
Так зачем делать работу, по обучению AST в макросы?
Приведите пожалуйста примеры, какой именно новый функционал получаем, с данным предложением. Да, заставить макросы работать по правилам C++ - это приятно, но слишком много нюансов и проблем возникает, пока кажется что овчинка не стоит выделки
Идея https://github.com/cpp-ru/ideas/issues/622 предлагает экспортировать макросы из global module fragment для именованных модулей. https://github.com/cplusplus/papers/issues/2316 предлагал то же самое
Та часть вашего предложениея, что
никак не сможет работать с модулями. Именованный модуль уже "запечён", и в него ничего больше не прилетает. Такой модуль - это практически иммутабельный бинарный блоб. Что-то схожее предлагалось в https://github.com/cplusplus/papers/issues/2316 и комитет был против
Вроде бы уже всё есть. Можете пожалуйста привести пару примеров, чего не хватает?
Международный комитет выступил против подобной идеи https://github.com/cplusplus/papers/issues/2316
Если хочется продолжить работу - нужна новая, более внушительная, мотивация
С C++20 основная засада - модули. Остальное всё уже реализовано, но модули - очень большая и многогранная фича, требующая работы над множеством частей C++ (форнтенд и мидленд компилятора, линкеры, системы сборки, библиотеки, ...)
В С++23 и C++26 нет таких "монстров", так что должно всё гладко идти и вендоры быстро наверстают отставание
Оно уже распараллелено, насколько это возможно. Однако, есть критические секции, которые не паралеллятся или плохо паралеллятся
Как ни странно - да. C++ чуть ли не единственный современный язык программирования, который можно использовать в приложениях, напрямую влияющих на жизнь человека (самолёты, автомобили, медицинское оборудование, ...). А для такого использования нужна ISO стандартизация.
Без этого - потеряется ощутимая часть пользователей
Не в курсе, я удалённо участвовал :)
Но не удивлюсь, если офлайн участники тоже не знают какая там погода - обычно времени на осмотр окресностей нет, график очень плотный, а в больших аудиториях с окнами зачастую напряжёнка
Основной смысл - общий сбор, точка синхронизации и формального голосования. Онлайн тоже есть, но встреча работает эффективнее
Выпуск стандарта ещё влечёт за собой накладные расходы - формальное создание особого черновика, сбор коментариев от стран, испраление замечаний, финализация стандарта в вышестоящих инстанциях ISO... Это достаточто ресурсоёмкие процессы
Пока кажется что 3 года - отличный баланс между скоростью выпуска новых фичей и уменьшением мороки для людей в комитете
Ну, во первых, ещё не отлито. Во вторых, рефлексия уже лет 7 варится, времени повлиять у заинтресованных людей было предостаточно. В третьих, мало того что целая прорва постов была во множестве соц сетей, так и несколько рабочих прототипов на godbolt.
За эти годы рефлексия активно менялась под фидбеком пользователей. И менялись важные фундаментальные части: ушли от шаблонов к type erased meta::info, репортить ошибки стали через исключения и т.д.
И если самая большая проблема рефлексии, это необходимость использовать
:вместо предпочитаемого вами@- то всё сделано комитетом просто замечательно.Вот именно! У вас есть возможность повлиять на результат. Но ведь высказывать "фи" намного проще, чем прорабатывать и продумывать идеи
Обратной связи много, но дельных мыслей и рабочих идей - крайне мало. Как правило связь вида "не программирую, но осуждаю" или "ну наконец, отлично!", или "мне не нравится синтаксис, вот вам другой сомнительный синтаксис".
Вот например у статьи уже набралось почти пол сотни комментариев. Есть ли средини них хоть пара, с которыми можно работать?
Ваше предложение по ссылке не позволяет получить информацию о том, позвали
&&функцию илиconst&функцию. Соответсвенно вы потеряли огромный кусок функционала, получив синтаксис не лучше чем с deducing this