Create spec for const expressions for is patterns

[Rekkonnect]

Spec for #6926

CC @333fred

[333fred]

This isn't a language concern. The compiler is free to make most-specific errors if it can and it would be helpful. It doesn't need to be specified.

[333fred]

This is overly specific. For example, it would prevent this code, which I would expect to be valid:

const int i = (1 is 2) ? 3 : 4;

[Rekkonnect]

I didn't intend to exclude support for this valid expression, and I think the document doesn't imply the inability to use constant pattern expressions in the evaluated expression of a conditional operator

[CyrusNajmabadi]

the wording says:

With this change, constant fields and locals of type bool may be assigned pattern expressions,

Which indicates, only fields/locals could benefit from this. My recommendation would be to go to the part of the spec on constant evaluation and just update it as necessary. The cases you want will fall out. By adding these extra clauses, it seems to be adding more restrictive requirements.

[CyrusNajmabadi]

like comparing against a range (e.g. x is >= 'a' and 'z')

i'm confused by this statement. 'is' is not prohibited in either of these cases. Both are legal.

[Rekkonnect]

Bad wording, I meant that we are not currently able to use this kind of syntax for that purpose, and use that result as a const expression. Will update to make it clearer.

[CyrusNajmabadi]

presumably the not, and and or patterns should also work.

[Rekkonnect]

And parenthesized ones too? I didn't initially consider them to be separate kinds of patterns.

[CyrusNajmabadi]

i'd enumerate the exact set of patterns we expect this to work for (same as how we enumerate the exact set of unary and binary operators, etc.). note: based on how the constant-expressions spec works out, i think everything else will likely fall out.

You can then give examples for each case. I don't htink you have to specify how it evaluates as the constant expression section already says this:

Whenever an expression fulfills the requirements listed above, the expression is evaluated at compile-time. This is true even if the expression is a subexpression of a larger expression that contains non-constant constructs.

The compile-time evaluation of constant expressions uses the same rules as run-time evaluation of non-constant expressions, except that where run-time evaluation would have thrown an exception, compile-time evaluation causes a compile-time error to occur.

--

Note: @333fred if we're doing this spec, would it makes sense to roll in switch expressions at the same time, given that the lang already supports ?:? Or would you prefer to keep that excluded? Thanks!

[333fred]

LDM did express interest in it, but didn't directly approve it. Probably best to leave it as an open question for now.

[CyrusNajmabadi]

That works for me. We could bring for an LDM read and easily add if desired.

[Rekkonnect]

Note, there is a discussion for the equivalent extension to support switch expressions in #7489, which will also be noted in the spec doc

[333fred]

Can we remove the word literal from these? It doesn't seem to be necessary, given the recursive nature of "constant expressions must be composed of other constant expressions", and it will reduce the brittleness here for future changes.

[333fred]

We need to see the actual spec changes here. How do we have to redefine the sections that specify these constructs to introduce a constant context? What is the definition of a constant context itself?

[Rekkonnect]

Updated ptal

[333fred]

Suggested change

	Constant context includes contexts where a constant expression is required, as indicated in the [§12.23 section](https://github.com/dotnet/csharpstandard/blob/standard-v7/standard/expressions.md#1223-constant-expressions), specifically:
	Constant contexts are contexts where a constant expression is required, as indicated in the [§12.23 section](https://github.com/dotnet/csharpstandard/blob/standard-v7/standard/expressions.md#1223-constant-expressions), specifically:

[333fred]

I'm not sure what this means?

[333fred]

Let's add some more examples. All of the examples here are always true, we want some always false as well. Let's also throw in some switch expression examples with proposed behavior; I don't want to go through the whole specification of switch expressions yet, but we can at least include some examples to demonstrate warning behavior for unreachable arms/locations where the arms don't cover the whole input range (ie, when you cover case 1 and 2, but not 3-uint.MaxValue).

[Rekkonnect]

I believe we should also support tuple pattern matching expressions of the form (x, y) is (a, b), when x and y are also constants. This tuple syntax does not create a tuple value, but instead deconstructs the expression into two comparisons of the two values, equivalent to x is a && y is b. This can be evaluated in compile time, and thus is eligible for being supported from this change.

I did not add the above to the spec before discussing the idea, since it deviates from the classical concept of a constant expression by being primarily driven by syntactical simplification.

[333fred]

I believe we should also support tuple pattern matching expressions of the form (x, y) is (a, b), when x and y are also constants.

I don't think I'm willing to champion this. These are not constants today, and will need a good deal of language and compiler changes to implement. Let's keep the proposal to just the things that have been championed.

[333fred]

This doesn't seem quite right, and LDM was concerned by the specific behavior that you show examples of below. We wanted to limit the subsumption changes to only constant contexts.

[Rekkonnect]

Is it fine if we make raise the warning into an error if we fail to match any subpattern in the constant switch? The constant value cannot be assigned without being provided a value from the default case, should all others fail to match.

For example,

const int a = 4;
// ERROR: No subpattern is matched, and the assigned value is a constant
const int c = a switch
{
    1 => 2,
    2 => 3,
    3 => 5,
};

// WARNING: No subpattern is matched, the default case will be handled and it will throw at runtime.
int v = a switch
{
    1 => 2,
    2 => 3,
    3 => 5,
};

I believe that both of the above cases should be an error, but I'd like your input about those.

[333fred]

The second case should have unchanged behavior from today. The first case would indeed be an error.

[333fred]

In general, the wording itself is not what I expected here. I don't see any mention of constant contexts, which is what I am expecting to drive changes in warning behavior.

[333fred]

LDM was specifically interested in making this not change behavior.

[333fred]

2 problems with this:

1. This is actually missing a case. b is false, and a is c is true.
2. The overall switch expression should not change behavior, which is to say it should still warn about missing cases.

[333fred]

I would not expect to get a warning here.