Code Generation: async Task and ValueTask Expressions w/ System.Linq.Expressions

[hivanov]

In S.L.Expressions, we have almost all building blocks needed for custom code generation.
What we lack, however, is the ability to create async methods with this tool set. I believe we are almost there, having the ability to create custom functions, and call them with S.L.E.Expression.Invoke().
It is not trivial to create an async function with this tool set, however -- the compiler generates quite a lot of code, which is very hard to track and emulate by hand.

In the past, S.L.E name space was declared feature complete. However, the language moves forward, and the tool set provided inside that name space lags behind since .net core 1.

Ideally, I would like to have feature parity with Roslyn, sans the Lexer and Parser, to be able to generate methods and classes with that name space. Currently, we are depending on Castle Windsor's DynamicProxy library, which, with some extensions, can barely handle regular Task and Task async methods. It is totally inadequate for Value Tasks, however. It's design is outdated and relies heavily on reflection.

Our other alternatives are:

• Create a code generator (either Roslyn, or T4), which builds compile-time classes. This is very time-consuming, error-prone, and a nightmare to maintain.
• Create in-memory Roslyn C#script. This adds around 3-4 gigs of ram to any executable, as a sunk cost, which cannot be reclaimed. It is not suitable for Docker images and microservises.

Can we please add to System.Linq.Expressions:

• ability to create classes and methods (same as class builder);
• ability to create asynchronous methods, both Tasks and ValueTasks?

[Joe4evr]

#2545

[BreyerW]

@hivanov unfortunetly if you want inbox solution you are out of luck because S.L.E is practically obsoleted for all intent and purposes and runtime team is not going to spend a dime fixing S.L.E (i mean bringing up to parity with new constructs)