Proposal: Allow switch expressions in expression trees

[hazzik]

It will be god to be able to use switch expression in expression trees.

Expression<Func<int?, string>> i = x => x switch
{
    null => "null",
    1 => "1",
    _ => "default"
};

Expression tree do support Expression.Switch, so the snipped above could be translated to following expression tree:

var parameter = Expression.Parameter(typeof(int), "x");
var expression = Expression.Lambda<Func<int?, string>>(
    Expression.Switch(parameter,
        Expression.Constant("default", typeof(string)),
        Expression.SwitchCase(
            Expression.Constant("null", typeof(string)),
            Expression.Constant(null, typeof(int?))),
        Expression.SwitchCase(
            Expression.Constant("1", typeof(string)),
            Expression.Constant(1, typeof(int?)))),
    parameter);

However Expression.Switch supports only constant comparison. So, it might be a good idea to translate to a set of Expression.Condition instead.

[ufcpp]

#158

[333fred]

To be clear: the cost of adding new things to expression trees is extremely high. We wouldn't do it for just one feature. Is it moving the goalposts? Maybe a bit. But you won't see progress on this piece until you see progress on the whole package.

[333fred]

Just to clarify: the main reason this discussion exists is to transition this particular feature into a proposal stage.

The proposals already exist, and they're the ones ufcpp linked.

[hazzik]

The proposals already exist, and they're the ones ufcpp linked.

sorry Fred I wrote my last message before I saw the last comment from ufcpp.

the cost of adding new things to expression trees is extremely high.

Apparently it took me much less time to implement the thing (from zero knowledge of Roslyn source code) than finding a correct way to submit it.

[333fred]

Apparently it took me much less time to implement the thing (from zero knowledge of Roslyn source code) than finding a correct way to submit it.

Lowering (which you showed an example of for an extremely basic case of a switch expression that has no nested pattern matching) is only half the issue, and it's the easy half. The real problem is that consumers of expression trees will not understand the resulting trees. Sure, the compiler could produce these nodes from an expression tree, but EF isn't going to know how to turn that into SQL and the code will fail at runtime. I'd suggest looking through the linked issues, particularly the second one, and reading the summaries of the issues with evolving the API before suggesting that it's simple.

[hazzik]

The real problem is that consumers of expression trees will not understand the resulting trees.

This is the exact reason I suggested to rewrite into ConditionalExpression which is understandable by most Linq providers.

I'd suggest looking through the linked issues, particularly the second one

I did read it. And it is indeed really hard to implement one solution for all missing tree expression features.

I’m going to abandon this issue and focus on the linked issue instead.