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.”

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.

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` involving `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` involving `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?

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

;

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 };

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?

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".

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...)

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?

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


		### §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.

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 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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RexJaeschke commented Aug 4, 2023 •

edited

Loading

Nigel-Ecma left a comment •

edited

Loading

Nigel-Ecma Oct 29, 2023 •

edited

Loading

Nigel-Ecma Jul 10, 2024 •

edited

Loading

Nigel-Ecma Oct 27, 2023 •

edited

Loading

Nigel-Ecma Oct 27, 2023 •

edited

Loading