- Allow the user to write any lambda expression
- Delegate the implementation to Func<> or Expression<Func<>> in a dynamic late-bound fashion.
- A way to turn Expression<Func<>> into a Func<> (i.e. an Expression<Func<>> runtime compiler / code generator).
- A way to express the actual argument type of a lambda expression that does not encode the choice between Expression<Func<>> and Func<>, and rather leaves the decision open.
- A way to turn a Func<> into an Expression<Func<>>.
Option 2 would be most flexible, but would require additional syntax, and would complicate the language further.
Option 1 is probably the best option: it could use Lightweight Code Generation. A cost of Option 1 would possibly be duplicated code, if the same (either isomorphic or referentially identical) expression tree was used in more than one place.
Option 1 gets my vote, not that it counts for much.
How to delay / hide / wrap decision between Func<> and Expression<Func<>>
perool
This sample to big and very difficult. It is desirable add simple sample demonstrate this technics.
PS
And... I'd like to see this feature at the compile-time (not only at run-time). it's open the wold of metaprogramming and make C# powerful language.
Rulli76
The Espresso example that comes with the LINQ install actually implements option 1.
Anders
chinafax
Remember that Reflector is able to, for the most part, do the more difficult problem of taking IL and turning it not into an abstract expression tree, but into legible source code.