Add support for new pattern kinds #873

RexJaeschke · 2023-08-04T17:54:00Z

Prior to V8, we have a term “switch expression” defined as the expression inside parens in a switch statement.

Now, we’re introducing a switch as an expression, and we have a new grammar rule called switch_expression. The difference between “switch expression” (without a *…* fence or separating underscore) and *switch_expression* likely is too subtle. So, how to differentiate them?

Although C calls such a switch expression a “controlling expression” (and uses that term as well for if, while, for, and do statements), we already state, “The governing type of a switch statement is established by the switch expression.”

As such, I have replaced all occurrences of “switch expression” (which exist only in the statements chapter) with “switch’s governing expression.”

Fixes #576.
Fixes #300.

BillWagner · 2023-09-25T14:16:40Z

Successfully rebased on the updated draft-v8 branch on 09/25/2023

Nigel-Ecma

I haven't managed to work my way through all of this yet but am submitting what I have so far. Overall this seems to have carried over too much non-Standardese from the original proposals and some issues repeating/rewording stuff already in the Standard.. There are also grammar issues that may break expression parsing…

Nigel-Ecma · 2023-10-27T09:09:22Z

standard/expressions.md

+
+```ANTLR
+switch_expression
+    : range_expression 'switch' '{' (switch_expression_arms ','?)? '}'


Something has gone wrong here:

range_expression does not appear to be defined anywhere

it appears the intention is to slot switch_expression between multiplicative_expression & unary_expression in the expression hierarchy, if this is the case then switch_expression needs to include unary_expression so as not to break the grammar layering

range_expression is defined by the V8 PR #605, "Add Support for Indexers and Ranges," which has not yet been merged.

Thanks @RexJaeschke. From #605 we have:

range_expression : unary_expression | range_expression? '..' range_expression? ;

This does connect to unary_expression but the grammar is still broken. The switch_expression grammar allows for empty braces,switch { }, which doesn’t seem right, was the intended grammar:

switch_expression : range_expression ( 'switch' '{' switch_expression_arms ','? '}' )? ;

I haven't checked that all fits (see next para) but it makes a bit more logical sense and should at least fix the layering issue.

Also how is e switch { ... } switch { ... } to be handled, if at all? I.e. using one switch to provide the value to switch on for a second (third, …) one? Something like:

switch_expression : range_expression | switch_expression ( 'switch' '{' switch_expression_arms ','? '}' )? ;

might be wanted, but that is left-recursive… Requiring parentheses ((e switch { ... }) switch { ... } is another option.

Fix to my own comment of Oct 30, 2023: It doesn’t matter if the rule is left recursive per se. While we avoid it when not required, left/right recursion is the way left/right associativity is represented.

So the question here is how should switch { … } switch { … } switch { … } associate, if it is supported?

Probably right associative surely?

Once supported/associtivity is decided the grammar will follow… (famous last words ;-))

(I haven’t checked what any implementation does)

Since the switch expression has only one value operand, there is no associativity issue. There is only one way it could possibly associate. According to the compiler, the following precedence levels are from looser to tighter:

Multiplicative, Switch, Range, Unary,

A switch expression may indeed have a switch expression as its left operand.

Syntactically, a switch expression's block may be empty. Because of the target-typing rule, there are legal programs that contain no switch expression arms, such as this statement: int x = 1 switch {}; (which will always throw an exception and produces a warning that "The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern '_' is not covered.").

However, without a target type it is expected to be a semantic error, because there is no common type among the switch arms.

The (left) operand to a switch expression may be a switch expression:

switch_expression : range_expression | switch_expression 'switch' '{' ( switch_expression_arms ','? )? '}' ;

I suppose we ought to reorganize this to avoid left recursion:

switch_expression | range_expression ( 'switch' '{' ( switch_expression_arms ','? )? '}' )* ;

There is no issue of precedence of a switch expression because it has no right-hand expression operand. There is only one possible way to interpret a switch { b => c } switch { d => e }.

@gafter – There is no need to remove self left-recursion in this sort of case, it occurs a lot in the grammar – stick with the first grammar which follows the pattern of many rules in the expression stack.

I must admit I’ve just jumped into this but “there are legal programs that contain no switch expression arms” followed an example that always throws an exception is, lets say, curious. Is there a no-arm example which doesn’t always throw? (Would not a better warning include that fact that it will throw?)

Whatever the answer the semantics need to be clearly defined in the Standard, and this comment suggests to me they are not.

Nigel-Ecma · 2023-10-27T09:10:32Z

standard/expressions.md

+    : switch_expression
+    | multiplicative_expression '*' switch_expression
+    | multiplicative_expression '/' switch_expression
+    | multiplicative_expression '%' switch_expression


Something has gone wrong here, see comment on line 3565 above

This should be resolved if suggestions above are adopted.

Nigel-Ecma · 2023-10-27T09:18:19Z

standard/expressions.md

+<!-- markdownlint-disable MD028 -->
+
+<!-- markdownlint-enable MD028 -->
+> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` involved `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.


The preceding note on line 4085 needs work and is covered under issue #935. This note also needs work (style, “first thing found”, etc.) and is related so maybe should be covered under #935 as well; i.e. remove it here and add a comment to #935.

Suggested change

> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` involved `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.

> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` on the right-hand-side of `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.

(Agree with involved => involving, but also that we need to tighten up the language.)

Nigel-Ecma · 2023-10-27T09:20:24Z

standard/expressions.md

@@ -4438,6 +4498,8 @@ For an expression of the form `E is P`, where `E` is a relational expression of
 - `E` does not designate a value or does not have a type.
 - The pattern `P` is not applicable ([§11.2](patterns.md#112-pattern-forms)) to the type `T`.

+Every *identifier* of the pattern introduces a new local variable that is definitely assigned once the corresponding *relational_expression* tests `true`.


“…assigned if the…” maybe? "Once" sounds like it is a temporal thing waiting on the relational expression to become true.

The section on definite assignment is in variables.md and needs to be extended to cover the is-pattern operator.

Nigel-Ecma · 2023-10-27T09:32:53Z

standard/patterns.md

+
+### §positional-pattern-new-clause Positional pattern
+
+A *positional_pattern* checks that the input value is not `null`, invokes an appropriate `Deconstruct` method ([§12.7](expressions.md#127-deconstruction)), and performs further pattern matching on the resulting values.  It also supports a tuple-like pattern syntax (without the type being provided) when the type of the input value is the same as the type containing `Deconstruct`, or if the type of the input value is a tuple type, or if the type of the input value is `object` or `System.ITuple` and the runtime type of the expression implements `System.ITuple`.


This feels like it is repeating stuff which is (or should be, e.g. System.ITuple is not in §12.7 at present) in §12.7 Deconstruction and this here should be something like:

A positional_pattern checks that the input value is not null, performs a deconstruction (§12.7), and performs further pattern matching on the resulting values.

Nigel-Ecma · 2023-10-27T09:48:07Z

standard/patterns.md

    ;
 single_variable_designation
    : identifier
    ;
 ```

+> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*


We have not previously specified that the alternatives in a C# grammar rule are ordered, even though we use ANTLR as a notation. Rather we have specified a disambiguation rule, and sometimes a note saying ANTLR semantics give an implementer a free implementation of the rule; e.g. in §12.19.1 we have:

When recognising an anonymous_function_body if both the null_conditional_invocation_expression and expression alternatives are applicable then the former shall be chosen.

Note: The overlapping of, and priority between, alternatives here is solely for descriptive convenience; the grammar rules could be elaborated to remove the overlap. ANTLR, and other grammar systems, adopt the same convenience and so anonymous_function_body has the specified semantics automatically. end note

This note here should either be re-written in our current style or we should re-consider how we describe overlapping/ambiguous alternatives and re-write them all to consistent to whatever we decide.

I think the note should say that a single_variable_designation cannot be the identifier _, which is taken as a discard_designation.

OK, my suggestion following the pattern of §12.19.1:

Suggested change

> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*

When recognising an *simple_designation* if both the *discard_designation* and *single_variable_designation* alternatives are applicable then the former shall be chosen.

> *Note*: Using ANTLR *simple_designation* will have the required semantics automatically, as ANTLR adopts the convenience of selecting the first alternative when multiple alternatives are applicable. *end note*

Possible wording for @gafter’s follows, 👍 which you prefer…

And possible wording for @gafter’s suggestion:

Suggested change

> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*

The *identifier* of a *single_variable_designation* may not be “_”.

> Note: This restriction exists to avoid an ambiguity in *simple_designation*.

(@gafter – feel free to reword!)

👍 your pick…

Nigel-Ecma · 2023-10-27T09:55:11Z

standard/patterns.md


 Each pattern form defines the set of types for input values that the pattern may be applied to. A pattern `P` is *applicable to* a type `T` if `T` is among the types whose values the pattern may match. It is a compile-time error if a pattern `P` appears in a program to match a pattern input value ([§11.1](patterns.md#111-general)) of type `T` if `P` is not applicable to `T`.

 Each pattern form defines the set of values for which the pattern *matches* the value at runtime.

+With regard to the order of evaluation of operations and side effects during pattern-matching, an implementation is permitted to reorder calls to `Deconstruct`, property accesses, and invocations of methods in `System.ITuple`, and it may assume that returned values are the same from multiple calls. The implementation should not invoke functions that cannot affect the result.


Line 192 below says the order is not specified, so an implementation cannot “reorder” – it just picks an order. What the Standard needs to say is that the order of operations, and any resulting side effects, is implementation defined/specified or unspecified (whichever term from the collection is appropriate here).

The last sentence (“The implementation should not invoke functions that cannot affect the result”) is either redundant or should be a Note.

In code such as

var x = e switch { A(1, 2) => 1 _ => 1 }

Is the compiler allowed to get the properties and test the values of A, or is that not allowed because it does not affect the 'result'?

How normative is a 'should' and what is a 'result'?

gafter · 2024-12-15T01:31:21Z

standard/patterns.md


 Each pattern form defines the set of types for input values that the pattern may be applied to. A pattern `P` is *applicable to* a type `T` if `T` is among the types whose values the pattern may match. It is a compile-time error if a pattern `P` appears in a program to match a pattern input value ([§11.1](patterns.md#111-general)) of type `T` if `P` is not applicable to `T`.

 Each pattern form defines the set of values for which the pattern *matches* the value at runtime.

+With regard to the order of evaluation of operations and side effects during pattern-matching, an implementation is permitted to reorder calls to `Deconstruct`, property accesses, and invocations of methods in `System.ITuple`, and it may assume that returned values are the same from multiple calls. The implementation should not invoke functions that cannot affect the result.


In code such as

var x = e switch { A(1, 2) => 1 _ => 1 }

Is the compiler allowed to get the properties and test the values of A, or is that not allowed because it does not affect the 'result'?

How normative is a 'should' and what is a 'result'?

gafter · 2024-12-15T01:32:56Z

standard/expressions.md

+<!-- markdownlint-disable MD028 -->
+
+<!-- markdownlint-enable MD028 -->
+> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` involved `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.


Suggested change

> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` involved `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.

> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` on the right-hand-side of `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.

gafter · 2024-12-15T01:47:59Z

standard/patterns.md

@@ -2,7 +2,7 @@

 ## 11.1 General

-A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)) and in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)) to express the shape of data against which incoming data is to be compared. A pattern is tested against the *expression* of a switch statement, or against a *relational_expression* that is on the left-hand side of an `is` operator, each of which is referred to as a ***pattern input value***.
+A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)), in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)), and in a *switch_expression* (§switch-expression-new-clause) to express the shape of data against which incoming data is to be compared. Patterns may be recursive, so that parts of the data may be matched against ***sub-patterns***.  A pattern is tested against the *expression* of a switch statement, or against a *relational_expression* that is on the left-hand side of an `is` operator, each of which is referred to as a ***pattern input value***.


Suggested change

A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)), in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)), and in a *switch_expression* (§switch-expression-new-clause) to express the shape of data against which incoming data is to be compared. Patterns may be recursive, so that parts of the data may be matched against ***sub-patterns***. A pattern is tested against the *expression* of a switch statement, or against a *relational_expression* that is on the left-hand side of an `is` operator, each of which is referred to as a ***pattern input value***.

A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)), in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)), and in a *switch_expression* (§switch-expression-new-clause) to express the shape of data against which incoming data is to be compared. Patterns may be recursive, so that parts of the data may be matched against ***sub-patterns***.

A pattern is tested against a value in a number of contexts:

- In a switch statement, the *pattern* of a case label is tested against the *expression* of the switch statement.

- In an *is-pattern* operator, the *pattern* on the right-hand-side is tested against the expression on the left.

- In a switch expression, the *pattern* of a *switch_expression_arm* is tested against the expression on the switch-expression's left-hand-side.

- In nested contexts, the *sub-pattern* is tested against values retrieved from properties, fields, or indexed from other input values, depending on the pattern form.

The value against which a pattern is tested is called the ***pattern input value*** for the pattern.

👍’ed the above but a minor grammar question: should the first comma of each bullet be a semi-colon?

In nested contexts, the sub-pattern is tested against values retrieved from properties, fields, or indexed from other input values, depending on the pattern form.

When we get to C# 9 with parenthesized patterns and logical patterns, we might want to remember to come back if we don't generalize this statement now, since and takes two subpatterns that do not retrieve new values to test against.

gafter · 2024-12-16T20:48:20Z

standard/patterns.md

    ;
 single_variable_designation
    : identifier
    ;
 ```

+> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*


I think the note should say that a single_variable_designation cannot be the identifier _, which is taken as a discard_designation.

gafter · 2024-12-16T20:52:52Z

standard/patterns.md

    ;
 single_variable_designation
    : identifier
    ;
 ```

+> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*
+
 The runtime type of the value is tested against the *type* in the pattern using the same rules specified in the is-type operator ([§12.12.12.1](expressions.md#1212121-the-is-type-operator)). If the test succeeds, the pattern *matches* that value. It is a compile-time error if the *type* is a nullable value type ([§8.3.12](types.md#8312-nullable-value-types)). This pattern form never matches a `null` value.


The constraint

It is a compile-time error if the type is a nullable value type

Appears both here and a couple of paragraphs below.

gafter · 2024-12-16T21:19:29Z

standard/patterns.md

+It is a compile-time error to use a discard pattern in a *relational_expression* of the form *relational_expression* `is` *pattern* or a *switch_statement*.
+


Suggested change

It is a compile-time error to use a discard pattern in a *relational_expression* of the form *relational_expression* `is` *pattern* or a *switch_statement*.

It is a compile-time error to use a discard pattern in a *relational_expression* of the form *relational_expression* `is` *pattern* or as the pattern of a *switch_label*.

At least one compiler disagrees:

class _ { ... } ... _ p = new _(); if (p is _)

Produces a warning that _ refers to the type and not the discard pattern.

This is (unfortunately, blame history) probably the required semantics.

gafter · 2024-12-16T21:24:37Z

standard/patterns.md

+>
+> *end example*
+
+### §discard-pattern-new-clause Discard pattern


The subsumption and exhaustiveness subsections need to be revised to account for these new pattern forms.

gafter · 2024-12-16T21:29:58Z

standard/expressions.md

+
+```ANTLR
+switch_expression
+    : range_expression 'switch' '{' (switch_expression_arms ','?)? '}'


Since the switch expression has only one value operand, there is no associativity issue. There is only one way it could possibly associate. According to the compiler, the following precedence levels are from looser to tighter:

Multiplicative, Switch, Range, Unary,

A switch expression may indeed have a switch expression as its left operand.

gafter · 2024-12-16T21:37:00Z

standard/expressions.md

+switch_expression
+    : range_expression 'switch' '{' (switch_expression_arms ','?)? '}'
+    ;


Suggested change

switch_expression

: range_expression 'switch' '{' (switch_expression_arms ','?)? '}'

;

switch_expression

: switch_expression 'switch' '{' (switch_expression_arms ','?)? '}'

| range_expression

;

@gafter above changed the order of the alternatives but also allowed there to be no arms as per the original, however that is invalid as the switch must cover all possible values – that gives us:

Suggested change

switch_expression

: range_expression 'switch' '{' (switch_expression_arms ','?)? '}'

;

switch_expression

: switch_expression 'switch' '{' switch_expression_arms ','? '}'

| range_expression

;

No. When there is a target type it is possible for there to be no switch expression arms.
https://sharplab.io/#v2:CYLg1APgAgzABFATHAwnA3gWAFBzwxZLXfUgSwDsAXOADzgF44BGOAZwHcyqBjACwwBfANw5SgnIKA==

gafter · 2024-12-16T21:45:32Z

standard/expressions.md

+```
+
+A *switch_expression* may not be used as an *expression_statement*.
+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.


Suggested change

The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.

The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s. It is an error if no such type exists. The expression in every arm of the switch expression is implicitly converted (§switch-expression-conversion) to that type.

I think the “expressions appearing to the right of the => tokens of the switch_expression_arms” of the original might be a case for introducing an extra rule to the grammar so simply the language. First replace the switch_expression_arm rule (lines 3573-5) with:

switch_expression_arm : pattern case_guard? '=>' switch_expression_arm_expression ; switch_expression_arm_expression : expression ;

And then modify @gafter’s suggestion to match:

Suggested change

The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.

The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the *switch_expression_arm_expression*s. It is an error if no such type exists. The expression in every arm of the switch expression is implicitly converted (§switch-expression-conversion) to that type.

Do we actually need it to be an error for there to be no best common type? I'd only expect that to be a problem if we need the switch expression to have a type, e.g. for assignment to var. If we're just trying to convert the switch expression to a known type, it should be fine.

Example:

var now = DateTime.UtcNow; // Valid: every arm is implicitly convertible to string? string? x = now.Month switch { _ => null }; // Invalid: no best type var y = now.Month switch { _ => null };

This specification does not describe target-typed switch expressions. See
dotnet/csharplang#2389
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/patterns.md

The type of the switch_expression is the best common type (§12.6.3.15) of the expressions appearing to the right of the => tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted to that type. In addition, we add a new switch expression conversion, which is a predefined implicit conversion from a switch expression to every type T for which there exists an implicit conversion from each arm's expression to T.

We have to be careful defining when the common type must exist (when there is no target type) and when it doesn't (the switch is target-typed). The spec must say that when there is no target type, it is an error if there is no common type.

jskeet · 2025-02-18T11:32:16Z

standard/expressions.md

+    ;
+```
+
+A *switch_expression* may not be used as an *expression_statement*.


As always, I find "may not" to be somewhat ambiguous. Could we use "shall not" here?

Perhaps better: "is not", since it is simply not in the yield of the grammar of expression_statement.

jskeet · 2025-02-18T11:37:13Z

standard/expressions.md

+```
+
+A *switch_expression* may not be used as an *expression_statement*.
+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.


Do we actually need it to be an error for there to be no best common type? I'd only expect that to be a problem if we need the switch expression to have a type, e.g. for assignment to var. If we're just trying to convert the switch expression to a known type, it should be fine.

Example:

var now = DateTime.UtcNow; // Valid: every arm is implicitly convertible to string? string? x = now.Month switch { _ => null }; // Invalid: no best type var y = now.Month switch { _ => null };

jskeet · 2025-02-18T11:38:40Z

standard/expressions.md

+A *switch_expression* may not be used as an *expression_statement*.
+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
+It is an error if some *switch_expression_arm*'s pattern cannot affect the result because some previous pattern and guard will always match.
+A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input.  The compiler shall produce a warning if a switch expression is not exhaustive.


Suggested change

A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input. The compiler shall produce a warning if a switch expression is not exhaustive.

A switch expression is said to be *exhaustive* if every value of its input is handled by at least one arm of the switch expression. The compiler shall produce a warning if a switch expression is not exhaustive.

Or something like that - currently I read the proposal as "if there's some arm X such that X handles every value".

I like Jon's rewording.

jskeet · 2025-02-18T11:39:39Z

standard/expressions.md

+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
+It is an error if some *switch_expression_arm*'s pattern cannot affect the result because some previous pattern and guard will always match.
+A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input.  The compiler shall produce a warning if a switch expression is not exhaustive.
+At runtime, the result of the *switch_expression* is the value of the *expression* of the first *switch_expression_arm* for which the expression on the left-hand-side of the *switch_expression* matches the *switch_expression_arm*'s pattern, and for which the *case_guard* of the *switch_expression_arm*, if present, evaluates to `true`. If there is no such *switch_expression_arm*, the *switch_expression* throws an instance of the exception `System.Runtime.CompilerServices.SwitchExpressionException`.


Possibly reinforce that this last part can only happen if the switch expression is not exhaustive? (Or if there's a compiler bug that makes it think it's exhaustive when it isn't really...)

I don't know if it's necessary, except as a Note. The compiler emits a warning for a non-exhaustive switch expression, so it's a valid program for a non-exhaustive switch expression.

No. It turns out it can happen due to nulls too.

https://sharplab.io/#v2:CYLg1APgxAdgrgGwQQwEYIKYAJgEsDOamAsAFAACAzFuQExYDCWA3mVuzdeQIwBsNAFiwBZZLhgAKcQBcA/FgAeAShZsO6mVgCeWALyKs+AO65pAYwAWLLJoBeegHxZ6AXwDca9i7IugA===

jskeet · 2025-02-18T11:41:11Z

standard/expressions.md

+<!-- markdownlint-disable MD028 -->
+
+<!-- markdownlint-enable MD028 -->
+> *Note*: There is a grammar ambiguity between *type* and *constant_pattern* in a `relational_expression` involved `is`; either might be a valid parse of a qualified identifier. In such a case, only if it fails to bind as a type (for compatibility with previous versions of the language), is it resolved to be the first thing found (which must be either a constant or a type). This ambiguity is only present on the right-hand side of such an expression.


(Agree with involved => involving, but also that we need to tighten up the language.)

jskeet · 2025-02-18T11:51:06Z

standard/patterns.md

+
+- If *type* is omitted and the input value's type is a tuple type, then the number of subpatterns shall to be the same as the cardinality of the tuple. Each tuple element is matched against the corresponding *subpattern*, and the match succeeds if all of these succeed. If any *subpattern* has an *identifier*, then that shall name a tuple element at the corresponding position in the tuple type.
+- Otherwise, if a suitable `Deconstruct` exists as a member of *type*, it is a compile-time error if the type of the input value is not pattern-compatible with *type*. At runtime the input value is tested against *type*. If this fails, then the positional pattern match fails. If it succeeds, the input value is converted to this type and `Deconstruct` is invoked with fresh compiler-generated variables to receive the output parameters. Each value that was received is matched against the corresponding *subpattern*, and the match succeeds if all of these succeed. If any *subpattern* has an *identifier*, then that shall name a parameter at the corresponding position of `Deconstruct`.
+- Otherwise, if *type* is omitted, and the input value is of type `object`, `System.ITuple`, or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no *identifier* appears among the subpatterns, then the match uses `System.ITuple`.


Suggested change

- Otherwise, if *type* is omitted, and the input value is of type `object`, `System.ITuple`, or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no *identifier* appears among the subpatterns, then the match uses `System.ITuple`.

- Otherwise, if *type* is omitted, and the input value is of type `object` or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no *identifier* appears among the subpatterns, then the match uses `System.ITuple`.

(Basically this relies on the identity conversion from ITuple to ITuple which is, I believe, an implicit reference conversion.)

jskeet · 2025-02-18T11:51:40Z

standard/patterns.md

+- If *type* is omitted and the input value's type is a tuple type, then the number of subpatterns shall to be the same as the cardinality of the tuple. Each tuple element is matched against the corresponding *subpattern*, and the match succeeds if all of these succeed. If any *subpattern* has an *identifier*, then that shall name a tuple element at the corresponding position in the tuple type.
+- Otherwise, if a suitable `Deconstruct` exists as a member of *type*, it is a compile-time error if the type of the input value is not pattern-compatible with *type*. At runtime the input value is tested against *type*. If this fails, then the positional pattern match fails. If it succeeds, the input value is converted to this type and `Deconstruct` is invoked with fresh compiler-generated variables to receive the output parameters. Each value that was received is matched against the corresponding *subpattern*, and the match succeeds if all of these succeed. If any *subpattern* has an *identifier*, then that shall name a parameter at the corresponding position of `Deconstruct`.
+- Otherwise, if *type* is omitted, and the input value is of type `object`, `System.ITuple`, or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no *identifier* appears among the subpatterns, then the match uses `System.ITuple`.
+- Otherwise, the pattern is a compile-time error.


"results in" or something similar, rather than saying the pattern is an error? (Or perhaps "the pattern is invalid and a compile-time error shall be issued" or similar?

jskeet · 2025-02-18T11:54:04Z

standard/patterns.md

+> if (s is object o) ...  // o is of type object
+> if (s is string x1) ... // x1 is of type string
+> if (s is {} x2) ...     // x2 is of type string
+> if (s is {}) ...


It may be worth noting the difference between:

if (s is {} x2)

and

if (s is var x3)

... the latter only matches on non-null values, whereas var would match on null (and the type of x3 is string? instead of string in a nullable context). I only mention this as a reader might wonder why {} x2 is useful when var exists.

jskeet · 2025-02-18T12:03:51Z

standard/patterns.md

+
+```ANTLR
+property_pattern
+    : type? property_subpattern simple_designation?


I believe that type here can't be a nullable reference type or nullable value type. I suspect we need to state that.

jskeet · 2025-02-18T12:04:31Z

standard/patterns.md

+
+### §discard-pattern-new-clause Discard pattern
+
+Every expression matches the discard pattern, which results in the value of the expression being discarded.


Should we have this in italics or bold? We're defining a term, right?

BillWagner · 2025-07-02T19:40:43Z

See #579 for useful references.

jskeet · 2025-07-02T19:48:02Z

We should make sure we get the precedence right, as per #300.

gafter · 2025-07-02T21:01:30Z

@gafter will try to summarize where we are on this PR.

Nigel-Ecma · 2025-07-14T23:38:41Z

Prior to V8, we have a term “switch expression” defined as the expression inside parens in a switch statement.

Now, we’re introducing a switch as an expression, and we have a new grammar rule called switch_expression. The difference between “switch expression” (without a … fence or separating underscore) and switch_expression likely is too subtle. So, how to differentiate them?

Although C calls such a switch expression a “controlling expression” (and uses that term as well for if, while, for, and do statements), we already state, “The governing type of a switch statement is established by the switch expression.”

As such, I have replaced all occurrences of “switch expression” (which exist only in the statements chapter) with “switch’s governing expression.”

Fixes #576. Fixes #300.

Instead of “governing expression” I’ll offer “selector expression”, which is used by at least Java & Pascal.

jskeet · 2025-07-29T09:33:45Z

Instead of “governing expression” I’ll offer “selector expression”, which is used by at least Java & Pascal.

Selector expression works for me. Should we change to "selector type" as well, instead of "governing type"?

gafter · 2025-07-29T23:07:17Z

standard/expressions.md

+
+```ANTLR
+switch_expression
+    : range_expression 'switch' '{' (switch_expression_arms ','?)? '}'


Syntactically, a switch expression's block may be empty. Because of the target-typing rule, there are legal programs that contain no switch expression arms, such as this statement: int x = 1 switch {}; (which will always throw an exception and produces a warning that "The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern '_' is not covered.").

However, without a target type it is expected to be a semantic error, because there is no common type among the switch arms.

The (left) operand to a switch expression may be a switch expression:

switch_expression : range_expression | switch_expression 'switch' '{' ( switch_expression_arms ','? )? '}' ;

I suppose we ought to reorganize this to avoid left recursion:

switch_expression | range_expression ( 'switch' '{' ( switch_expression_arms ','? )? '}' )* ;

There is no issue of precedence of a switch expression because it has no right-hand expression operand. There is only one possible way to interpret a switch { b => c } switch { d => e }.

gafter · 2025-07-29T23:09:45Z

standard/expressions.md

+switch_expression
+    : range_expression 'switch' '{' (switch_expression_arms ','?)? '}'
+    ;


No. When there is a target type it is possible for there to be no switch expression arms.
https://sharplab.io/#v2:CYLg1APgAgzABFATHAwnA3gWAFBzwxZLXfUgSwDsAXOADzgF44BGOAZwHcyqBjACwwBfANw5SgnIKA==

gafter · 2025-07-29T23:10:51Z

standard/expressions.md

+    ;
+```
+
+A *switch_expression* may not be used as an *expression_statement*.


Perhaps better: "is not", since it is simply not in the yield of the grammar of expression_statement.

gafter · 2025-07-29T23:17:25Z

standard/expressions.md

+```
+
+A *switch_expression* may not be used as an *expression_statement*.
+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.


This specification does not describe target-typed switch expressions. See
dotnet/csharplang#2389
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/patterns.md

The type of the switch_expression is the best common type (§12.6.3.15) of the expressions appearing to the right of the => tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted to that type. In addition, we add a new switch expression conversion, which is a predefined implicit conversion from a switch expression to every type T for which there exists an implicit conversion from each arm's expression to T.

We have to be careful defining when the common type must exist (when there is no target type) and when it doesn't (the switch is target-typed). The spec must say that when there is no target type, it is an error if there is no common type.

gafter · 2025-07-29T23:20:36Z

standard/expressions.md

+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
+It is an error if some *switch_expression_arm*'s pattern cannot affect the result because some previous pattern and guard will always match.
+A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input.  The compiler shall produce a warning if a switch expression is not exhaustive.
+At runtime, the result of the *switch_expression* is the value of the *expression* of the first *switch_expression_arm* for which the expression on the left-hand-side of the *switch_expression* matches the *switch_expression_arm*'s pattern, and for which the *case_guard* of the *switch_expression_arm*, if present, evaluates to `true`. If there is no such *switch_expression_arm*, the *switch_expression* throws an instance of the exception `System.Runtime.CompilerServices.SwitchExpressionException`.


No. It turns out it can happen due to nulls too.

https://sharplab.io/#v2:CYLg1APgxAdgrgGwQQwEYIKYAJgEsDOamAsAFAACAzFuQExYDCWA3mVuzdeQIwBsNAFiwBZZLhgAKcQBcA/FgAeAShZsO6mVgCeWALyKs+AO65pAYwAWLLJoBeegHxZ6AXwDca9i7IugA===

gafter · 2025-07-29T23:21:19Z

standard/expressions.md

@@ -4177,7 +4233,11 @@ equality_expression
    ;
 ```

-> *Note*: Lookup for the right operand of the `is` operator must first test as a *type*, then as an *expression* which may span multiple tokens. In the case where the operand is an *expression*, the pattern expression must have precedence at least as high as *shift_expression*. *end note*
+> *Note*: Lookup for the right operand of the `is` operator must first test as a *type*, then as an *expression* which may span multiple tokens. In the case where the operand is an *expreesion*, the pattern expression must have precedence at least as high as *shift_expression*. *end note*


Suggested change

> *Note*: Lookup for the right operand of the `is` operator must first test as a *type*, then as an *expression* which may span multiple tokens. In the case where the operand is an *expreesion*, the pattern expression must have precedence at least as high as *shift_expression*. *end note*

> *Note*: Lookup for the right operand of the `is` operator must first test as a *type*, then as an *expression* which may span multiple tokens. In the case where the operand is an *expression*, the pattern expression must have precedence at least as high as *shift_expression*. *end note*

gafter · 2025-07-29T23:23:33Z

standard/expressions.md

@@ -4589,6 +4649,8 @@ For an expression of the form `E is P`, where `E` is a relational expression of
 - `E` does not designate a value or does not have a type.
 - The pattern `P` is not applicable ([§11.2](patterns.md#112-pattern-forms)) to the type `T`.

+Every *identifier* of the pattern introduces a new local variable that is definitely assigned once the corresponding *relational_expression* tests `true`.


Suggested change

Every *identifier* of the pattern introduces a new local variable that is definitely assigned once the corresponding *relational_expression* tests `true`.

Every *identifier* of the pattern introduces a new local variable that is definitely assigned where the corresponding *relational_expression* tests `true`.

Nigel-Ecma · 2025-07-29T23:40:06Z

Instead of “governing expression” I’ll offer “selector expression”, which is used by at least Java & Pascal.

Selector expression works for me. Should we change to "selector type" as well, instead of "governing type"?

I’m going to say no, the different names here makes sense to me, I think ;-)

jnm2

(More later)

jnm2 · 2025-07-29T20:22:38Z

standard/statements.md

@@ -729,17 +730,19 @@ switch_label
    ;

 case_guard
-    : 'when' expression
+    : 'when' null_coalescing_expression


What is the reason to specify null coalescing expressions for when clauses? If it is to block invalid expressions, I noticed that null_coalescing_expression would directly allow throw_expression. (https://github.com/dotnet/csharpstandard/blob/draft-v8/standard/expressions.md#1215-the-null-coalescing-operator) Throw expressions are not permitted by the current Roslyn compiler with any language version. Is this later language on line 737 sufficient to disallow throw expressions?

its expression shall be implicitly convertible to the type bool and that expression is evaluated as an additional condition for the case to be considered satisfied

And again so I can follow along, what is the reason to use null_coalescing_expression in particular?

Under expression there is a whole stack (with some branches) of rules/productions which controls how subexpressions are group, i.e. the precedence. Part way down is null_coalescing_expression and down at the bottom is parenthesized_expression.

What this change is doing is changing what can directly occur after a when without being in parenthesis. A common reason for doing this is to avoid parsing ambiguities that would occur is something is not wrapped in parenthesis and I guess that is why this change was made here – something between expression and null_coalescing_expression would cause a parsing ambiguity if it was not wrapped.

The important thing is this change is not changing what constructs are valid here, just which ones must be wrapped to be valid – which isn’t a semantic change per se. So throw is there either way, and if it is indeed invalid then there is, or should be, a semantic rule specifying that.

jnm2 · 2025-07-29T20:31:09Z

standard/patterns.md

@@ -2,7 +2,7 @@

 ## 11.1 General

-A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)) and in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)) to express the shape of data against which incoming data is to be compared. A pattern is tested against the *expression* of a switch statement, or against a *relational_expression* that is on the left-hand side of an `is` operator, each of which is referred to as a ***pattern input value***.
+A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)), in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)), and in a *switch_expression* (§switch-expression-new-clause) to express the shape of data against which incoming data is to be compared. Patterns may be recursive, so that parts of the data may be matched against ***sub-patterns***.  A pattern is tested against the *expression* of a switch statement, or against a *relational_expression* that is on the left-hand side of an `is` operator, each of which is referred to as a ***pattern input value***.


In nested contexts, the sub-pattern is tested against values retrieved from properties, fields, or indexed from other input values, depending on the pattern form.

When we get to C# 9 with parenthesized patterns and logical patterns, we might want to remember to come back if we don't generalize this statement now, since and takes two subpatterns that do not retrieve new values to test against.

jnm2 · 2025-07-30T13:56:32Z

standard/expressions.md

+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
+It is an error if some *switch_expression_arm*'s pattern cannot affect the result because some previous pattern and guard will always match.
+A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input.  The compiler shall produce a warning if a switch expression is not exhaustive.
+At runtime, the result of the *switch_expression* is the value of the *expression* of the first *switch_expression_arm* for which the expression on the left-hand-side of the *switch_expression* matches the *switch_expression_arm*'s pattern, and for which the *case_guard* of the *switch_expression_arm*, if present, evaluates to `true`. If there is no such *switch_expression_arm*, the *switch_expression* throws an instance of the exception `System.Runtime.CompilerServices.SwitchExpressionException`.


Suggested change

At runtime, the result of the *switch_expression* is the value of the *expression* of the first *switch_expression_arm* for which the expression on the left-hand-side of the *switch_expression* matches the *switch_expression_arm*'s pattern, and for which the *case_guard* of the *switch_expression_arm*, if present, evaluates to `true`. If there is no such *switch_expression_arm*, the *switch_expression* throws an instance of the exception `System.Runtime.CompilerServices.SwitchExpressionException`.

At runtime, the result of the *switch_expression* is the value of the *expression* of the first *switch_expression_arm* for which the expression on the left-hand-side of the *switch_expression* matches the *switch_expression_arm*'s pattern, and for which the *case_guard* of the *switch_expression_arm*, if present, evaluates to `true`. If there is no such *switch_expression_arm*, the *switch_expression* throws an instance of the exception `System.Runtime.CompilerServices.SwitchExpressionException` if this type is defined in the compilation or references at compile time, or an instance of `System.InvalidOperationException` otherwise.

This change does not seem right for the Standard, is it not adding an exception which a particular compiler uses when using an older version of its runtime? As such it is down to the implementation to document how it behaves in such a situation, while C# v8 specifies SwitchExpressionException. Or am I missing something?

jnm2 · 2025-07-30T16:52:20Z

standard/patterns.md

+- If *type* is omitted and the input value's type is a tuple type, then the number of subpatterns shall to be the same as the cardinality of the tuple. Each tuple element is matched against the corresponding *subpattern*, and the match succeeds if all of these succeed. If any *subpattern* has an *identifier*, then that shall name a tuple element at the corresponding position in the tuple type.
+- Otherwise, if a suitable `Deconstruct` exists as a member of *type*, it is a compile-time error if the type of the input value is not pattern-compatible with *type*. At runtime the input value is tested against *type*. If this fails, then the positional pattern match fails. If it succeeds, the input value is converted to this type and `Deconstruct` is invoked with fresh compiler-generated variables to receive the output parameters. Each value that was received is matched against the corresponding *subpattern*, and the match succeeds if all of these succeed. If any *subpattern* has an *identifier*, then that shall name a parameter at the corresponding position of `Deconstruct`.
+- Otherwise, if *type* is omitted, and the input value is of type `object`, `System.ITuple`, or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no *identifier* appears among the subpatterns, then the match uses `System.ITuple`.
+- Otherwise, the pattern is a compile-time error.


Patterns (including property patterns and positional patterns) implicitly unwrap System.Nullable<T>, as part of their "checks that the input value is not null." Do we need to say something to this effect here?

Example:

class C { void M(Point? p) { if (p is (var x, var y)) // True { } } } struct Point { public int X, Y; public void Deconstruct(out int x, out int y) { x = X; y = Y; } }

Nothing needs to be said, that's how checking whether a Nullable<T> is null works, which is defined elsewhere in the Standard.

jnm2 · 2025-07-30T19:13:58Z

standard/patterns.md

+subpatterns
+    : subpattern (',' subpatterns)?
+    ;
+subpattern
+    : pattern
+    | identifier ':' pattern
+    ;


(In future versions of C#, there will be other kinds of subpatterns besides property subpatterns and positional subpatterns, such as <subpattern> and <subpattern> in C# 9, or is [<subpattern, <subpattern>] later on. At that point, calling this definition subpattern will seem overly broad.)

jskeet · 2025-07-30T19:22:31Z

We'll go with selector expression, but keep governing type.

@gafter will attempt to get this ready for review for the September meeting.

BillWagner · 2025-02-18T15:40:28Z

standard/expressions.md

+A *switch_expression* may not be used as an *expression_statement*.
+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
+It is an error if some *switch_expression_arm*'s pattern cannot affect the result because some previous pattern and guard will always match.
+A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input.  The compiler shall produce a warning if a switch expression is not exhaustive.


I like Jon's rewording.

BillWagner · 2025-02-18T15:43:01Z

standard/expressions.md

+The type of the *switch_expression* is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the *switch_expression_arm*s if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
+It is an error if some *switch_expression_arm*'s pattern cannot affect the result because some previous pattern and guard will always match.
+A switch expression is said to be *exhaustive* if some arm of the switch expression handles every value of its input.  The compiler shall produce a warning if a switch expression is not exhaustive.
+At runtime, the result of the *switch_expression* is the value of the *expression* of the first *switch_expression_arm* for which the expression on the left-hand-side of the *switch_expression* matches the *switch_expression_arm*'s pattern, and for which the *case_guard* of the *switch_expression_arm*, if present, evaluates to `true`. If there is no such *switch_expression_arm*, the *switch_expression* throws an instance of the exception `System.Runtime.CompilerServices.SwitchExpressionException`.


I don't know if it's necessary, except as a Note. The compiler emits a warning for a non-exhaustive switch expression, so it's a valid program for a non-exhaustive switch expression.

BillWagner · 2025-09-12T16:56:22Z

standard/expressions.md

@@ -3884,6 +3940,7 @@ The `*`, `/`, `%`, `+`, and `-` operators are called the arithmetic operators.
 ```ANTLR
 multiplicative_expression
    : range_expression
+    | switch_expression


This needs more work (see other comments on grammar). I added this as a placeholder to remember it while addressing merge conflicts.

RexJaeschke added the type: feature This issue describes a new feature label Aug 4, 2023

RexJaeschke added this to the C# 8.0 milestone Aug 4, 2023

RexJaeschke self-assigned this Aug 4, 2023

RexJaeschke marked this pull request as draft August 4, 2023 17:54

add new implicit conversion

237570c

BillWagner force-pushed the add-new-pattern-kinds branch from 0d6dda3 to 237570c Compare September 25, 2023 14:15

gafter self-assigned this Oct 4, 2023

RexJaeschke added 7 commits October 7, 2023 12:55

Merge branch 'dotnet:draft-v8' into add-new-pattern-kinds

4b81948

add support for new pattern kinds

1522c30

add support for new pattern kinds

cb21c50

add support for new pattern kinds

4bba228

fix new grammar rule

9f776c0

separate consecutive block quotes

f1a889e

separate note and example

29b0013

RexJaeschke added the Review: pending Proposal is available for review label Oct 13, 2023

Nigel-Ecma requested changes Oct 27, 2023

View reviewed changes

RexJaeschke added 3 commits October 29, 2023 12:17

use correct grammar rule name

14fd17d

fix example annotation formatting

a2a2b78

fix md formatting

1475a9b

RexJaeschke mentioned this pull request Dec 7, 2023

Add support for pattern additions #1026

Draft

Merge branch 'dotnet:draft-v8' into add-new-pattern-kinds

2e48fe0

RexJaeschke mentioned this pull request Jan 3, 2024

8.0 Tuple parentheses optional in switch expression and statement #576

Open

RexJaeschke marked this pull request as ready for review January 11, 2024 14:08

gafter self-requested a review January 16, 2024 18:41

Update patterns.md

0592ce8

gafter requested changes Dec 16, 2024

View reviewed changes

gafter removed their assignment Dec 16, 2024

gafter added Review: complete at least one person has reviewed this and removed Review: pending Proposal is available for review labels Dec 16, 2024

RexJaeschke added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Feb 2, 2025

jskeet reviewed Feb 18, 2025

View reviewed changes

RexJaeschke added 2 commits May 28, 2025 10:58

Merge branch 'draft-v8' into add-new-pattern-kinds

cc4381a

fix links

2465de0

RexJaeschke removed their assignment Jun 11, 2025

RexJaeschke closed this Jun 23, 2025

RexJaeschke reopened this Jun 23, 2025

This was referenced Jul 2, 2025

[C# 8.0] Some references for pattern-matching #579

Closed

Change precedence of switch expression from relational to unary #300

Open

BillWagner mentioned this pull request Jul 2, 2025

13.8.3 The switch statement - edit loses base type text #131

Closed

jskeet added the meeting: priority Review before meeting. Merge, merge with issues, or reject at the next TC49-TC2 meeting label Jul 23, 2025

gafter reviewed Jul 29, 2025

View reviewed changes

jnm2 reviewed Jul 30, 2025

View reviewed changes

gafter self-assigned this Jul 30, 2025

Merge branch 'draft-v8' into add-new-pattern-kinds

162ff39

BillWagner reviewed Sep 12, 2025

View reviewed changes


		### §positional-pattern-new-clause Positional pattern

		A positional_pattern checks that the input value is not `null`, invokes an appropriate `Deconstruct` method ([§12.7](expressions.md#127-deconstruction)), and performs further pattern matching on the resulting values. It also supports a tuple-like pattern syntax (without the type being provided) when the type of the input value is the same as the type containing `Deconstruct`, or if the type of the input value is a tuple type, or if the type of the input value is `object` or `System.ITuple` and the runtime type of the expression implements `System.ITuple`.

-> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*
+When recognising an *simple_designation* if both the *discard_designation* and *single_variable_designation* alternatives are applicable then the former shall be chosen.
+> *Note*: Using ANTLR *simple_designation* will have the required semantics automatically, as ANTLR adopts the convenience of selecting the first alternative when multiple alternatives are applicable. *end note*

-> *Note*: The ordering of the grammar rules in *simple_designation* is important. By putting *discard_designation” first, the source token `_` is recognized as a discard rather than as a named identifier. *end note*
+The *identifier* of a *single_variable_designation* may not be “_”.
+> Note: This restriction exists to avoid an ambiguity in *simple_designation*.

-A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)), in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)), and in a *switch_expression* (§switch-expression-new-clause) to express the shape of data against which incoming data is to be compared. Patterns may be recursive, so that parts of the data may be matched against ***sub-patterns***.  A pattern is tested against the *expression* of a switch statement, or against a *relational_expression* that is on the left-hand side of an `is` operator, each of which is referred to as a ***pattern input value***.
+A ***pattern*** is a syntactic form that can be used with the `is` operator ([§12.12.12](expressions.md#121212-the-is-operator)), in a *switch_statement* ([§13.8.3](statements.md#1383-the-switch-statement)), and in a *switch_expression* (§switch-expression-new-clause) to express the shape of data against which incoming data is to be compared. Patterns may be recursive, so that parts of the data may be matched against ***sub-patterns***.
+A pattern is tested against a value in a number of contexts:
+- In a switch statement, the *pattern* of a case label is tested against the *expression* of the switch statement.
+- In an *is-pattern* operator, the *pattern* on the right-hand-side is tested against the expression on the left.
+- In a switch expression, the *pattern* of a *switch_expression_arm* is tested against the expression on the switch-expression's left-hand-side.
+- In nested contexts, the *sub-pattern* is tested against values retrieved from properties, fields, or indexed from other input values, depending on the pattern form.
+The value against which a pattern is tested is called the ***pattern input value*** for the pattern.

		It is a compile-time error to use a discard pattern in a relational_expression of the form relational_expression `is` pattern or a switch_statement.

	The type of the switch_expression is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the expressions appearing to the right of the `=>` tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted (§switch-expression-conversion) to that type.
	The type of the switch_expression is the best common type [§12.6.3.15](expressions.md#126315-finding-the-best-common-type-of-a-set-of-expressions)) of the switch_expression_arm_expressions. It is an error if no such type exists. The expression in every arm of the switch expression is implicitly converted (§switch-expression-conversion) to that type.

	A switch expression is said to be exhaustive if some arm of the switch expression handles every value of its input. The compiler shall produce a warning if a switch expression is not exhaustive.
	A switch expression is said to be exhaustive if every value of its input is handled by at least one arm of the switch expression. The compiler shall produce a warning if a switch expression is not exhaustive.

	- Otherwise, if type is omitted, and the input value is of type `object`, `System.ITuple`, or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no identifier appears among the subpatterns, then the match uses `System.ITuple`.
	- Otherwise, if type is omitted, and the input value is of type `object` or some type that can be converted to `System.ITuple` by an implicit reference conversion, and no identifier appears among the subpatterns, then the match uses `System.ITuple`.


		### §discard-pattern-new-clause Discard pattern

		Every expression matches the discard pattern, which results in the value of the expression being discarded.

	> Note: Lookup for the right operand of the `is` operator must first test as a type, then as an expression which may span multiple tokens. In the case where the operand is an expreesion, the pattern expression must have precedence at least as high as shift_expression. end note
	> Note: Lookup for the right operand of the `is` operator must first test as a type, then as an expression which may span multiple tokens. In the case where the operand is an expression, the pattern expression must have precedence at least as high as shift_expression. end note

	Every identifier of the pattern introduces a new local variable that is definitely assigned once the corresponding relational_expression tests `true`.
	Every identifier of the pattern introduces a new local variable that is definitely assigned where the corresponding relational_expression tests `true`.

Add support for new pattern kinds #873

Are you sure you want to change the base?

Add support for new pattern kinds #873

Uh oh!

Conversation

RexJaeschke commented Aug 4, 2023 • edited by jskeet Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BillWagner commented Sep 25, 2023

Uh oh!

Nigel-Ecma left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma Oct 29, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma Jul 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gafter Dec 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma Oct 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma Oct 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gafter Dec 15, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RexJaeschke commented Aug 4, 2023 •

edited by jskeet

Loading

Nigel-Ecma left a comment •

edited

Loading

Nigel-Ecma Oct 29, 2023 •

edited

Loading

Nigel-Ecma Jul 10, 2024 •

edited

Loading

gafter Dec 15, 2024 •

edited

Loading

Nigel-Ecma Oct 27, 2023 •

edited

Loading

Nigel-Ecma Oct 27, 2023 •

edited

Loading

gafter Dec 15, 2024 •

edited

Loading