Extended property patterns


This article is a feature specification. The specification serves as the design document for the feature. It includes proposed specification changes, along with information needed during the design and development of the feature. These articles are published until the proposed spec changes are finalized and incorporated in the current ECMA specification.

There may be some discrepancies between the feature specification and the completed implementation. Those differences are captured in the pertinent language design meeting (LDM) notes.

You can learn more about the process for adopting feature speclets into the C# language standard in the article on the specifications.


Allow property subpatterns to reference nested members, for instance:

if (e is MethodCallExpression { Method.Name: "MethodName" })

Instead of:

if (e is MethodCallExpression { Method: { Name: "MethodName" } })


When you want to match a child property, nesting another recursive pattern adds too much noise which will hurt readability with no real advantage.

Detailed design

The property_pattern syntax is modified as follow:

  : type? property_pattern_clause simple_designation?

  : '{' (subpattern (',' subpattern)* ','?)? '}'

- : identifier ':' pattern
+ : subpattern_name ':' pattern

+ : identifier 
+ | subpattern_name '.' identifier
+ ;

The receiver for each name lookup is the type of the previous member T0, starting from the input type of the property_pattern. if T is a nullable type, T0 is its underlying type, otherwise T0 is equal to T.

For example, a pattern of the form { Prop1.Prop2: pattern } is exactly equivalent to { Prop1: { Prop2: pattern } }.

Note that this will include the null check when T is a nullable value type or a reference type. This null check means that the nested properties available will be the properties of T0, not of T.

Repeated member paths are allowed. The compilation of pattern matching can take advantage of common parts of patterns.