С первой предварительной версии прошло 2.5 года.
Успели обсудить и тут

Автор: Serginio1
Дата: 01.05.20

тоже.

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

                return $@"
private static {JsonSerializerOptionsTypeRef} {DefaultOptionsStaticVarName} {{ get; }} = new {JsonSerializerOptionsTypeRef}()
{{
    DefaultIgnoreCondition = {JsonIgnoreConditionTypeRef}.{options.DefaultIgnoreCondition},
    IgnoreReadOnlyFields = {ToCSharpKeyword(options.IgnoreReadOnlyFields)},
    IgnoreReadOnlyProperties = {ToCSharpKeyword(options.IgnoreReadOnlyProperties)},
    IncludeFields = {ToCSharpKeyword(options.IncludeFields)},
    WriteIndented = {ToCSharpKeyword(options.WriteIndented)},{namingPolicyInit}
}};";

Кто работает с этим, вы тоже так делаете ?

Я бы ожидал за это время, что работу с объектами, а не оставят очередной T4 / текстовой препроцессор.

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

_NN>Даже в самом коде .NET пишут напрямую текст, а не создали объектную модель языка:

Насколько я помню, там этот текст потом парсится и превращается в модель Розлина. Просто в таком виде запись намного компактнее, чем ручная сборка модели.

_NN>Кто работает с этим, вы тоже так делаете ?
Увы, да. Квазицитирования нет и вроде как не планируется.

_NN>Я бы ожидал за это время, что работу с объектами, а не оставят очередной T4 / текстовой препроцессор.
Я надеялся что возьмут парсинг от dynamic, к нему сделают типизацию, и всякие удобные методы вроде ToTypedExpression() и ToRoslynAst(). Но уже не надеюсь

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

_NN>Кто работает с этим, вы тоже так делаете ?
Да, тоже так.
Подозреваю, что есть способ лучше (потому что уж очень корявым выглядит код по конверсии AST обратно в текст C#), но я его не освоил.
Ну, вот в частности:
https://github.com/evilguest/ConstructorInheritor/blob/master/Constructor.Inheritor/Constructor.Inheritor/InheritedConstructorGenerator.cs#L116
и
https://github.com/evilguest/ConstructorInheritor/blob/master/Constructor.Inheritor/Constructor.Inheritor/InheritedConstructorGenerator.cs#L120:L124
Это же позоруха какая-то:

        private string GenerateRefKind(RefKind refKind) => refKind switch
        {
            RefKind.None => "",
            RefKind.Ref => "ref ",
            RefKind.Out => "out ",
            RefKind.RefReadOnly => "ref readonly",
            _ => throw new ArgumentException("Unknown RefKind value", nameof(refKind)),
        };

При этом фиксы реализуются вполне себе в модели редактора, через AST.
Вот, к примеру, как добавить к декларации класса partial:

        private static async Task<Document> AddPartialAsync(Document document, Diagnostic makePartial, CancellationToken cancellationToken)
        {
            var root = await document.GetSyntaxRootAsync(cancellationToken);

            if (root is null)
                return document;

            var classDeclaration = FindClassDeclaration(makePartial, root);

            var partial = SyntaxFactory.Token(SyntaxKind.PartialKeyword);
            var newDeclaration = classDeclaration.AddModifiers(partial);
            var newRoot = root.ReplaceNode(classDeclaration, newDeclaration);
            var newDoc = document.WithSyntaxRoot(newRoot);

            return newDoc;
        }

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

Ну это проще чем разбираться с Рослин API (Microsoft.CodeAnalysis.CSharp) (MSBuildWorkspace,CSharpSyntaxTree.ParseText,CompilationUnitSyntax)
На самом то деле если наблатыкаться то как раз проще использовать классы Рослина для модификации.
Просто порог вхождения хотя и небольшой, но требует времени

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

_>Я надеялся что возьмут парсинг от dynamic, к нему сделают типизацию, и всякие удобные методы вроде ToTypedExpression() и ToRoslynAst(). Но уже не надеюсь
Не вполне представляю как это...

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

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

_NN>Кто работает с этим, вы тоже так делаете ?
Ну конкретно Source Generators мне писать сейчас не приходится, но был опыт написания генераторов ранее, а текущее SG — просто способ удобно добавить генератор в pipeline сборки (баз всяких сложностей с MSbuild, например).

Поэтому, честно говоря, я не знаю, что можно было бы предложить более удобного взамен...
Если отбросить, упомянутое выше квазицитирование (за неимением оного в C#), то остаются:
— StringBuilder-style
— текстовые шаблонизаторы (не обязательно T4. Откровенно говоря, зачастую хватает куда более простых, типа scriban-а)
— AST-based (типа CodeDOM или Roslyn)
— ну и смешанные варианты, вроде того, что упомянул выше коллега Ночной Смотрящий (когда исходный текст-заготовка парсится, а потом переводится в AST, с которым идут какие-то преобразования).
Вроде всё?

И вот если положить руку на сердце, то из всего вышеперечисленного самый наглядный, на мой вкус, это текстовые шаблоны (ну кроме ситуации, когда логика генерации такая, что на 100 строк генератора приходится 1 сгенерированная строка).
Ради интереса можно взглянуть на реализации одного и того же примитивного генератора POCO-объектов (публичные классы, с публичными свойствами — всё)
— на базе AST
CodeDom
Roslyn (через SyntaxGenerator)

— на базе шаблонов
Scriban (это расширенный Liquid)
T4
Razor (хотя этот, скорее, за компанию)

У генераторов на базе AST (в теории) будут такие плюсы:
— поддержка нескольких выходных языков (не факт)
— некоторые проверки сгенерированного текста или, если мы говорим о чем-то типа CodeDOM, то там само API вносит ряд ограничений, поэтому, например, засунуть объявление класса внутрь тела метода не получится (у SyntaxGenerator в Roslyn некоторые ограничения тоже есть, но их куда меньше, увы).
— возможность менять уже сгенерированный (или распарсенный) AST. Вот только для чисто генерации это, имхо, не нужно (разве что вы пишите генератор, который можно будет расширять сторонним разработчикам. Тогда да, будет удобно: вы сгенерировали основу, а всякие плагины доработали ваш результат. С шаблонами такое не пройдет).

Как-то так.

P.S. Я не претендую на полноту, не исключено, что я просто не знаю действительно удобных способов генерации, помимо перечисленного мною.

Здравствуйте, Михаил Романов, Вы писали:

МР>У генераторов на базе AST (в теории) будут такие плюсы:
МР>- поддержка нескольких выходных языков (не факт)
МР>- некоторые проверки сгенерированного текста или, если мы говорим о чем-то типа CodeDOM, то там само API вносит ряд ограничений, поэтому, например, засунуть объявление класса внутрь тела метода не получится (у SyntaxGenerator в Roslyn некоторые ограничения тоже есть, но их куда меньше, увы).
МР>- возможность менять уже сгенерированный (или распарсенный) AST. Вот только для чисто генерации это, имхо, не нужно (разве что вы пишите генератор, который можно будет расширять сторонним разработчикам. Тогда да, будет удобно: вы сгенерировали основу, а всякие плагины доработали ваш результат. С шаблонами такое не пройдет).

Ты самый главнй плюс забыл — возможности реюза на уровне C#. У того же T4 и прочих шаблонизаторов с этим все сильно хуже.
Поэтому примеры, когда чтото генерируется на уровне самого низкоуровневого AST не особо показательны. Потому что в реальных генераторах ты все более менее общие юзкейсы завернешь в удобные обертки.

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

_>Увы, да. Квазицитирования нет и вроде как не планируется.

Ну, в МС о них знают (так как они есть в F#). Так что вопрос в созревании. За 10 лет они дозрели до ФП и зачаточного генератора кода, который не развивается. Значит нужно подождать еще 10 лет или сделать самим. Ну, или юзать Немерл. За 20 лет он ни фига не устарел.