switch expression involving constant expressions should be considered constant

[Rekkonnect]

Following #6925, which is championed in #6926

Summary

When evaluating and returning only constant expressions, using a switch expression is not considered constant. This can be safely adjusted.

Motivation

Conditional compilation symbols, reliance on runtime constants deriving from conditional statements

Description

You cannot assign a switch expression only involving constant values to a constant symbol. For example,

public const int A = 4;
// currently illegal, despite being capable of evaluating during compile time
public const int B = A switch
{
    1 or 2 => 0,
    > 6 => 1,
    _ => 2,
};

In the example above, the evaluated expression (A) is a constant, and the returned expressions are also constant.

Any throw expression would result in a compiler error, saying "the constant result evaluates into throwing an exception". If the throw expression is not reached, there will be no compiler error.

If any non-constant expression is returned, even when the resulting branch does not reach it, the entire switch expression is considered to not be constant, and a specific compiler error would be returned showing that some expressions are not constant.

Example

In the following example:

public const int A = 1;
public const int B = A switch
{
    1 or 2 => throw null,
    > 6 => throw new UnreachableException(),
    _ => 1,
};

The result would be B having the value 1 if A is <= 6 and not 1 and not 2. Otherwise, a compiler error would be thrown indicating that the resulting branch is a throw expression.

In the following example:

public const int A = 1;
public const int B = A switch
{
    1 or 2 => throw null,
    > 6 => nameof(B).Length, // the Length property is not evaluated in compile time
    _ => 1,
};

The arm for the > 6 condition does not return a constant expression, and so the entire switch expression is considered non-constant.

[333fred]

For your last two examples, I don't believe ternary works this way. Everything involved needs to be constants, and I don't see the point in doing otherwise.

[Rekkonnect]

But if the switch isn't exhaustive, then the constant evaluator either reaches a handled branch, or it doesn't. If it fails to find a handled branch, a compiler error occurs, which would be about the unhandled case, that would otherwise throw a runtime exception if reached.

The user wouldn't have to evaluate all cases in most hard-coded scenarios where a constant is involved. Therefore, being lenient about that handling is friendlier for the user. Once they reach an unexpected constant value, they get the appropriate error about failing to handle the current case of the constant.

Since we have now dove into the hole of handling thrown exceptions in compile-time evaluation, we can also allow throw expressions in the arms' returns, and the compiler would then cause a compiler error, indicating the arm that is reached and potentially the message of the exception that would be thrown.

[HaloFour]

If it fails to find a handled branch, a compiler error occurs, which would be about the unhandled case

Yes, which is completely sufficient to me.

Since we have now dove into the hole of handling thrown exceptions in compile-time evaluation

There is no hole, exceptions aren't thrown during compilation, and it seems like quite a stretch to go from non-exhaustive switch expressions to making throw expressions constant and related to compiler errors.

[333fred]

The primary reason I wanted throw expressions to be allowed in constant evaluation is that omitting the default value arm would automatically throw an exception

This doesn't make any sense to me. Either there's a constant answer to the switch expression's input (ie, it's exhaustive), or it isn't. A default value doesn't need to be part of that equation. For example, this is exhaustive: const int i = 1 switch { 1 => 2 };. No default branch is required. That handling is part of what you need to design here, and if the implementation wants to allow various constant folding that the compiler does not do today for non-constant expressions, that's perfectly fine. But when an expression actually has a constant value, it must be composed entirely of constant expressions, and throw is not a constant expression, nor am I interested in championing making it one.

[Rekkonnect]

Oh so by exhaustive you mean whether the evaluated expression matches any arm. I'll agree that specific user error handling doesn't really have a place, and failing to match a branch would simply report a compiler error. That's very fine by me.

[HaloFour]

That's a good point, the compiler would know if an int constant is a certain value, so it's not like a switch over that constant would need to cover the entire range of possible int values. It only needs to cover that one constant value, which the compiler can verify at compile-time. So I'd amend my previous statement that the switch doesn't need to be "exhaustive", it just needs to cover the known case at compile-time.

[CyrusNajmabadi]

Won't this also just come with warnings about unreachable branches?

[Rekkonnect]

The point is to not warn about unreachable branches, like in the ternary operator. It is meant to help in conditional compilation snippets, and bloating the diagnostics list with warnings wouldn't come off nicely I believe.

[CyrusNajmabadi]

It is meant to help in conditional compilation snippets,

Can you give an example of this then? Thanks!

[Rekkonnect]

Assume you define an enum const field based on a preprocessing symbol, and you switch that enum value and map it to a number denoting the number of errors before force shutting down the app. In code,

public const EnvironmentType Type =
#if DEBUG
    EnvironmentType.Debug
#elif DEV_TEST
    EnvironmentType.DevTest
...
#endif
    ;

public const int ErrorLenience = Type switch
{
    EnvironmentType.Debug => 3,
    EnvironmentType.DevTest => 1,
};

In the above code you reduce clutter with # directives by having defined a constant denoting the information those specific preprocessing symbols give. Then, you can switch over the constant value and conditionally define the field for error lenience.

[CyrusNajmabadi]

before force shutting down the app.

Why would this ever be a constant. As opposed to an environment control. This seems to violate serious best practices for dev v test envs.

[Rekkonnect]

I know, really failed to come up with a good example. Though this is primarily for switching over enum values that could be conditionally defined for some purpose. Hopefully a good example will cross this thread.