C# 11 Preview Updates – Raw string literals, UTF-8 and more!

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

S>C# 11 Preview Updates – Raw string literals, UTF-8 and more!

в первой фиче баксов маловато!

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

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

S>>C# 11 Preview Updates – Raw string literals, UTF-8 and more!

vaa>в первой фиче баксов маловато!
Но фича долгожданная!

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

S>C# 11 Preview Updates – Raw string literals, UTF-8 and more!
Ну, того чего я жду, так и нет.
1. Расширения в Expression Trees (https://github.com/bartdesmet/ExpressionFutures)
2. Expression Types https://github.com/bartdesmet/roslyn/blob/ExpressionTreeLikeTypes/docs/features/expression-types.md

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

S>C# 11 Preview Updates – Raw string literals

Raw string literals start and end with at least three double quotes ("""...""")

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

Неужели людям, вращающимся в компиляторостроении, ещё неведомо, что ЛЮБОЙ символ, который будет использован как ограничитель, сразу же у кого-то окажется в данных?! И очевидно, что "ограничитель" — вещь, которая должна быть отдана на откуп ПРОГРАММИСТУ — это он должен решать, чем ограничивать данные. Пример:

var s = ~%some data "not including percentage sign" is safe%;

Здесь тильда (~) — знак начала строки. Следующий символ — динамически выбирается девом, потому что только он знает, какие именно данные он передаёт. В данном случае выбран %. Аналогично:

var s = ~|any <b>html</b> code can be here|;

Если бы у тупоголовых индусов было бы хоть на пол-кило больше мозгов, идиотию с """"""" они бы в жизни не запилили!

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

Да как то они подзабросили Expression Trees. Хотя это мощнейшая штука

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

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

S>Да как то они подзабросили Expression Trees. Хотя это мощнейшая штука

Пару раз за жизнь их использовал (не помню зачем), но наверное полезно. А будет ли полноценной заменой (выражениям) создать на лету C# код и его сканпелять?

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

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

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

S>>Да как то они подзабросили Expression Trees. Хотя это мощнейшая штука

K>Пару раз за жизнь их использовал (не помню зачем), но наверное полезно. А будет ли полноценной заменой (выражениям) создать на лету C# код и его сканпелять?
Это значительно дольше и требует Roslyn
.Net Core, 1C, динамическая компиляция, Scripting API

Здравствуйте, Kolesiki, Вы писали:
K>Пару раз за жизнь их использовал (не помню зачем), но наверное полезно. А будет ли полноценной заменой (выражениям) создать на лету C# код и его сканпелять?
Нет, не будет.
ET позволяют делать всякие прикольные штуки типа того же linq.
Весь смысл как раз в том, чтобы писать "обычный" C#-код, который превращается в AST, а не в MSIL. И потом это AST можно как-то анализировать и трансформировать.
Проблемы с нынешним состоянием этого раздела две:
1. Большинство фич, добавленных после C# 3.0, в Expression Tree недоступны. Понятно, что большинство из них там и не нужны, но, скажем, поддержки Tuple там сильно не хватает
2. Компилятор не знает, для чего может потребоваться Expression Tree, поэтому компилирует всё подряд. В том числе и код, который заведомо не удастся обработать выбранным провайдером.

Решения для обеих проблем есть. По первой есть Expression Futures, по второй есть идея использовать специальный провайдер.
Типа сейчас компилятор вызывает статические методы класса Expression; почему бы не дать возможность указать другой класс, методы которого вызывать.
Потенциально можно возвращать из них экземпляры произвольных типов, не обязательно из иерархии Expression. Но важно не это, а возможность проверить порождаемый код, не дожидаясь вызова провайдера.

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

S>Здравствуйте, Kolesiki, Вы писали:
K>>Пару раз за жизнь их использовал (не помню зачем), но наверное полезно. А будет ли полноценной заменой (выражениям) создать на лету C# код и его сканпелять?
S>Нет, не будет.
S>ET позволяют делать всякие прикольные штуки типа того же linq.
S>Весь смысл как раз в том, чтобы писать "обычный" C#-код, который превращается в AST, а не в MSIL. И потом это AST можно как-то анализировать и трансформировать.

Как ни крути, а в конце концов получится LISP
Надо немерл юзать, там уже давно можно "анализировать и трансформировать".

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

S>Проблемы с нынешним состоянием этого раздела две:
S>1. Большинство фич, добавленных после C# 3.0, в Expression Tree недоступны. Понятно, что большинство из них там и не нужны, но, скажем, поддержки Tuple там сильно не хватает
S>2. Компилятор не знает, для чего может потребоваться Expression Tree, поэтому компилирует всё подряд. В том числе и код, который заведомо не удастся обработать выбранным провайдером.

S>Решения для обеих проблем есть. По первой есть Expression Futures, по второй есть идея использовать специальный провайдер.
S>Типа сейчас компилятор вызывает статические методы класса Expression; почему бы не дать возможность указать другой класс, методы которого вызывать.
S>Потенциально можно возвращать из них экземпляры произвольных типов, не обязательно из иерархии Expression. Но важно не это, а возможность проверить порождаемый код, не дожидаясь вызова провайдера.

Насколько я понимаю, такой подход позволит в компил-тайм отсечь только языковые фичи, которые не поддерживает конкретный провайдер. Но, ИМХО, в большинстве случает нужно не языковые фичи отсекать, а использование неизвествных провайдеру методов/свойств/классов. Как использование "Expression Types" из твоей ссылки поможет в этом случае?

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

J>Насколько я понимаю, такой подход позволит в компил-тайм отсечь только языковые фичи, которые не поддерживает конкретный провайдер. Но, ИМХО, в большинстве случает нужно не языковые фичи отсекать, а использование неизвествных провайдеру методов/свойств/классов. Как использование "Expression Types" из твоей ссылки поможет в этом случае?
Напрямую — увы, никак. Но можно будет вызывать конструирование делегата прямо в IDE — статик методам не нужны экземпляры. Это даст возможность генерировать warnings.

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

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

J>>Насколько я понимаю, такой подход позволит в компил-тайм отсечь только языковые фичи, которые не поддерживает конкретный провайдер. Но, ИМХО, в большинстве случает нужно не языковые фичи отсекать, а использование неизвествных провайдеру методов/свойств/классов. Как использование "Expression Types" из твоей ссылки поможет в этом случае?
S>Напрямую — увы, никак. Но можно будет вызывать конструирование делегата прямо в IDE — статик методам не нужны экземпляры. Это даст возможность генерировать warnings.

Имеются в виду static методы этого класса Quote ??

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

J>Имеются в виду static методы этого класса Quote ??
Ага. Вызывать методы Expression смысла нет — они прожуют всё, что угодно. А вот у Quote их можно и позвать.

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

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

J>>Имеются в виду static методы этого класса Quote ??
S>Ага. Вызывать методы Expression смысла нет — они прожуют всё, что угодно. А вот у Quote их можно и позвать.

Мне все равно понятно, как это в целом будет работать. Вот есть код:

// пусть есть формочка, на ней два Edit'а, в edId юзер пишет ID сущности, в edCaption программа выводит наименование этой сущности.
using var db = new MyDbContext();
edCaption.Text = db.MyTable.Where(x => CompareInt(x.Id, int.Parse(edId.Text)).Select(x => x.Caption).First();
static bool CompareInt(int a, int b) => a == b;

Провайдер не умеет CompareInt и хотелось бы в компил тайм получить warning на этот счет. Как это технически можно сделать имея наш Quote ? Ну можно вызывать его статические методы, но что на вход им подавать ?? Откуда в компил тайм мы получим доступ к edId

Здравствуйте, Jack128, Вы писали:
J>Провайдер не умеет CompareInt и хотелось бы в компил тайм получить warning на этот счет. Как это технически можно сделать имея наш Quote ? Ну можно вызывать его статические методы, но что на вход им подавать ?? Откуда в компил тайм мы получим доступ к edId
Давайте попробуем разобраться.
Компилятор порождает примерно такой код:

var xParam = Expression.Parameter("x", typeof(MyTableRow));

var predicate = Expression.Lambda<Func<MyTableRow, bool>>(
  Expression.Call(
    null, // статический метод
    typeof(MyClass).GetMethod("CompareInt"),  // тут на самом деле сразу стоит methodToken, но в C# нет аналогичной конструкции
    xParam,
    Expression.Call(
      null, 
      typeof(int).GetMethod("Parse"),
      Expression.Property(
        Expression.Constant(edId),
        "Text"
      )
    )
  ),
  new ParameterExpression[] { xParam  }
)

В перспективе — ровно то же самое, только вместо Expression будет Quote (подразумеваем, что у myTable.Where — подходящий тип аргумента).

Да, в рантайме нам потребуется ссылка на настоящий edId. А вот в компайл-тайме можно было бы попробовать все неконстантные аргументы заменять на default. Это никак не помешает нам в Quote.Call посмотреть на MethodInfo и принять решение, можно ли с ним работать. А константы в конце концов всё равно отрезолвятся в некую константу при свёртке дерева — причём это можно делать даже не внутри .Where или там .ToArray, а прямо в Quote.xxx.

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

S>Да, в рантайме нам потребуется ссылка на настоящий edId. А вот в компайл-тайме можно было бы попробовать все неконстантные аргументы заменять на default. Это никак не помешает нам в Quote.Call посмотреть на MethodInfo и принять решение, можно ли с ним работать. А константы в конце концов всё равно отрезолвятся в некую константу при свёртке дерева — причём это можно делать даже не внутри .Where или там .ToArray, а прямо в Quote.xxx.

Всё тоже самое можно провернуть и с ExpressionTree и получившийся Extression<> отдать какому нить аналайзеру, специфичному для провайдера. И это не требует никаких изменений в языке.

Здравствуйте, Jack128, Вы писали:
J>Всё тоже самое можно провернуть и с ExpressionTree и получившийся Extression<> отдать какому нить аналайзеру, специфичному для провайдера. И это не требует никаких изменений в языке.
В теории — да; но как мы будем пришивать к провайдеру этот аналайзер?

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

S>Здравствуйте, Jack128, Вы писали:
J>>Всё тоже самое можно провернуть и с ExpressionTree и получившийся Extression<> отдать какому нить аналайзеру, специфичному для провайдера. И это не требует никаких изменений в языке.
S>В теории — да; но как мы будем пришивать к провайдеру этот аналайзер?

Не понял вопрос? Я сам аналайзеры не писал, может чего не понимаю, но в моем представлении всё должно работать примерно так:
Аналайзер берет AST аргумента нашего метода Where, строит Expression<> по алгоритму выше и анализирует этот Expression. Нет, в принципе он может и не строить Expression, а на прямую анализоровать рослиновское ast, только мне видится, что такие аналайзеры должны писать сами авторы провайдеров, а в коде провайдера анализ ExtressionTree уже есть и наверняка часть кода можно будет расшарить между провайдером и аналайзером.

Здравствуйте, Jack128, Вы писали:
J>Не понял вопрос? Я сам аналайзеры не писал, может чего не понимаю, но в моем представлении всё должно работать примерно так:
J>Аналайзер берет AST аргумента нашего метода Where, строит Expression<> по алгоритму выше и анализирует этот Expression.
Так он же должен быть специфичным для провайдера. Вот эта вот специфика — она откуда возьмётся?
У нас слева от .Where — абстрактный IQueryable<T>.

J>Нет, в принципе он может и не строить Expression, а на прямую анализоровать рослиновское ast, только мне видится, что такие аналайзеры должны писать сами авторы провайдеров, а в коде провайдера анализ ExtressionTree уже есть и наверняка часть кода можно будет расшарить между провайдером и аналайзером.
Это как раз понятно. Непонятно, как определить, какой из анализаторов вызывать для конкретной строчки исходника.