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

S>При этом этот add2 — это вовсе не вызов того же add с b=2, а по честному проинлайненный код делегата, соответствующий a=>a+2.
S>Для Expression это, понятное дало, тривиальное упражнение. А интересно, конечно, делать это для готовых делегатов.

Восстанавливать из тела делегата Expression, как это делает Reflector и другие подобные тулзы. ))


S>А уже потом поверх такой библиотеки можно делать различные прикольные плюшки типа "а давайте оптимизируем нашу цепочку цепочек делегатов".

Ес-но.


S>Но это всё тоже требует больших затрат

Ну вот, задача сформулирована — восстанавливать Expression из CIL.


S>Например, хорошо известная штука — в Expressions до сих пор нет поддержки Tuple Initializer или как он там называется.
S>То есть нельзя сделать
S>

S>Expression<Func<int, (int, int)>> t = a=>(a, a);
S>

S>Можно только
S>

S>Expression<Func<int, (int, int)>> t = a=>Tuple.Create(a, a);
S>

S>Хотя казалось бы — чего такого-то?

У меня вот так ругается:

Expression<Func<int, (int, int)>> t = a => Tuple.Create(a, a);

Вот так нет:

Expression<Func<int, Tuple<int, int>>> t2 = a => Tuple.Create(a, a);

А как вообще сюда напишешь расширение, если Expression порождает сам компилятор?
Я еще понимаю написать расширения к уже готовым экземплярам Expression...

Ниже вообще для меня новости.
Вот так ОК:

Func<int, int> f = a => {
    return a;
};

Вот так нельзя:

Expression<Func<int, int>> t3 = a => {
    return a;
};

Т.е. блоки для Expression нельзя.

Можно так:

Expression<Func<int, int>> t4 = a => a;

=================
Кароч, там еще пилить и пилить...