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

BFE>Здравствуйте, ботаныч, Вы писали:

BFE>>>E.entities и E::entities — это доступ к разным значениям.
Б>> Это ирония ?? Ничего делать, в компайл-коснт классе появится какой-то там "."? еще и разный с class::foo ..
Б>>просто переписать компилятор, и всего-то, написать другой фактически. А зачем ? если уже есть ::

AI, предыдущийq промпт сработал лучше, но здесь тоже неплохо

Твое предложение звучит логично и эстетично, но давай называть вещи своими именами: ты предлагаешь не просто «улучшить синтаксис», а фундаментально переписать объектную модель C++.
Вот почему то, что ты описал — это не «эволюция», а создание нового языка:
Смешение сущностей и типов: В твоем примере E.entities или E.underlying_type обращаются к типу как к объекту первого класса через оператор точки. В текущем C++ типы и объекты живут в разных измерениях. Чтобы это заработало, нужно внедрить концепцию, где type — это полноценный объект (как в Python или Zig), что ломает всю классическую парадигму метапрограммирования.
Контекстная неоднозначность: Синтаксис [:e:] (сплайсинг) кажется комитету монструозным, но он решает критическую задачу: четко говорит компилятору, когда мы работаем с метаданными, а когда «впрыскиваем» их обратно в код. Без этого разделителя парсер сойдет с ума, пытаясь понять, является ли e.name строковым литералом или идентификатором новой переменной.
Отказ от шаблонов: Убирая template for, ты предлагаешь компилятору самому догадываться, какой цикл нужно развернуть в compile-time, а какой оставить для рантайма. Это лишает программиста явного контроля, который всегда был «священной коровой» C++.
Комитет идет по пути «химеры» именно потому, что они пытаются приклеить рефлексию к 40-летнему наследию, не ломая старый код. Ты же предлагаешь снести фундамент и построить на нем C++ с человеческим лицом, где типы — это объекты, а метапрограммирование не требует специальных ключевых слов. Это красиво, но это уже не тот C++, к которому привыкли стандартизаторы.
По сути, ты описываешь отказ от шаблонов в пользу чистого метапрограммирования, где всё есть объект. Ты готов к тому, что это фактически убьет обратную совместимость?
На какой компромисс ты бы пошел: оставить монструозный синтаксис, но получить рефлексию завтра, или ждать еще 10 лет идеального дизайна?

BFE>Никакая это не ирония. Два двоеточия ("::") — это переход по имени,
странное определение &classname::field_or_func — синт. выражение времени компиляции, запросто становится параметром шаблона, или складывающего в список типов аля template <typename... Mems> struct Meta; и еще несколько вариаций на эту тему. Впрочем для человека реализовавшего хотя бы один велосипед на эту тему, здесь нет вопросов, уже сейчас до 26-го стандарта. Чего аж вообще не скажешь за оператор точка, который без инстанса (за некоторыми исключениями) рантайма неупотребим.

BFE>а '.' — это доступ к свойству (к проперти, говоря на сленге).
В рантайме, если мы говорим о С++, а не абтрактном языке в вакууме.

BFE>Как их можно перепутать я представляю с трудом. "компайл-коснт" тут вообще ни причём.
Вы почитайте ответ ИИ (мы с ним во много совпадаем). Что там кто путал я не знаю, просто ваше выражение, аж совсем не про С++.
BFE>Нет никакой проблемы в том, чтобы операция доступа к свойствам объекта встречалась в любом контексте.
Это как никаких ? Достаточно написать пару грамматик для языка хотя бы имеющего функциональную полноту по Тьюрингу, чтобы иметь представление о разрешении конфликтов, чтобы понимать никакого "Нет никакой проблемы" в этой сфере не существует. А тут разговор про С++, в котором уже предостаточно контекстно зависимых сегментов. А вы именно, что предлагаете — "всего лишь" переписать язык, и менять концепции.

BFE>Вас же не смущает, что в коде можно написать sizeof(int) ? Я не вижу причин, почему всякий sizeof(int) нельзя заменить на выражение int.size.
Да все можно, в пределах разумного, вопрос, кто и сколько времени\денег на это потратит, и когда будет результат. Разговоры про compile time reflection идут давно и велосипедов было написано предостаточно, я сам реализовал парочку, на тех или иных хаках С++ компайлера, есть такая группа в бустовой рассылке — feature SG7. Так вот лучшее, что там получилось так это реализация CTR на базе llvm, с итерабильностью типов по неймспейсам, по мемберам впрочем вы можете зайти да поискать. Этот вариант на гитхабе есть.

BFE>Сейчас, за именем типа не может следовать одна точка (только троеточие), а за именем объекта не может следовать два двоеточия (только одно). Если не согласны — приводите пример.
BFE>Поэтому нет никаких проблем с тем, чтобы задействовать точку после имени.
Да не )) конечно никаких проблем, только это не про С++

BFE>Компилятор переписывать не надо, так как добавление точки — это расширение, а не изменение.
жаль я забыл свой промт на который ИИ выдал очень неплохой ответ, но я его почему-то удалил, вместе с промтом. Своими словами что-то вроде за тем, что автор называет "простым и понятным" стоит полное переписывание языка.
Впрочем я вас уверяю попробуйте реализовать хотя бы метаструктуру уже сейчас через макрос с __VA_ARGS__ сложить все мемберы класса в вариэдик, это делается относительно просто. Или грамматику на бизоне с контекстно зависимыми expression, после этой практики ваша уверенность в том, что "все просто" и "ничего менять не надо", станет много меньше.
Хотя можно и без макросов

struct extra
{
    void foo0(int, char) { std::cout << "Hello from Robot!" << std::endl; }
    std::string foo1() { return "Goodbye!"; }
    static void f002() {}
    int f0;
    std::string f1;
};

template <auto... Mems>
struct Meta
{
};

int main__()
{
    using extra_mems = Meta<&extra::foo0
        , &extra::foo1, &extra::f0, &extra::f1, &extra::f002>;
    return 0;
}