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

EP>>Вопрос "зачем?" не раскрыт.
EP>>Я конечно представляю возможные варианты, и вначале доклада даже есть список ограничений C# — но чёткая область применения всё же не очерчена.
_>Ну началось всё, как я понял, просто как тест Roslyn'а.

Если так — то конечно тогда вопросов нет.

_>А в итоге может выйти инструмент, позволяющий "не погружаться в страшные плюсы". )))

Не погружаться чтобы получить что?
* Скорость? — не получится, точнее разве что самый минимум — семантика ведь вся остаётся, а именно она и ответственна за большую часть тормозов. Если на C++ писать в Java-style то мы и получим те же тормоза.
* Большую переносимость кода? Возможно, вот только портировать VM (а-ля Mono) было бы и мощнее, и надёжнее, и возможно проще.

EP>>По реализации:
EP>>* Для инициализации by-default там генерируется специальный код конструкторов для классов содержащие такие поля. Проще было бы сделать отдельный тип default_initialized<T>.
_>Как мне кажется, это не принципиально — замена одной кодогенерации на другую.

Это на порядок проще. Вместо того чтобы отслеживать все места где нужно не забыть сгенерировать инициализацию, можно просто заменить int32_t на default_initialized<int32_t> — и проблема решена.

EP>>Говорится что это демонстрация того что Roslyn работает быстро, при этом ничего похожего на замеры не было в докладе.
_>Нууу типа успевает парсить в реальном времени со вводом текста. )))

Цифры нужны, без них это всё сферически. Подобный код и Clang моментально пережёвывает.