Revisiting Pattern Matching And Switch Expressions

Introduction 

 

C# 7 introduced us to pattern matching and we have been falling in love with it so much that we didn't realize it was nonexistent prior to C#. Before we delve into the new patterns introduced in C# 8, let's take a quick recap of the pattern introduced in C# 7.

 

Const Pattern

 

The constant pattern extends the is statement to compare the expression to a constant. For example:

if(input is 7m)
{

}

or

const decimal VALUE = 7m;
if(input is VALUE)
{

}

The most common use case of the Constant Pattern is for checking null.

if(input is null)
{

}

var Pattern

Probably the least used among the patterns introduced in C# 7 is the var pattern. The var pattern is unique in its own way. It always succeeds.

So, what would be the use-case for something that always succeeds? Since the pattern always succeeds and the value is assigned to the variable, you could use the var pattern to create a temporary variable.

This is especially useful inside a linq query where you could create a temporary variable inside a where condition. For example:

var inputCollection = Enumerable.Range(1,100)
                                .Select(x=> Enumerable.Range(x,10).Select(c=>c*x));
var result = inputCollection.Where(x=> x.ToList() is var list
                                && list.Average() > 100);

 The var pattern is also useful inside the switch statement, especially when used with a case guard. For example:

private string Evaluate(int input)
{
    var inputCollection = Enumerable.Range(1,100)
                                     .Select(x=> Enumerable.Range(x,10).Select(c=>c*x));
    switch(input)
    {
        case 5:
            return "Five";
        case 4:
            return "Six";
        case var v when inputCollection.Any(x=>x.Contains(v)):
            return "Collection Contains the value";
        default :
            return "Not Found";
    }
}

Type Pattern

The most common pattern used would be the Type Pattern, which checks if the expression matches a type and if so, converts it to a particular type.

if(input is double val)
{
    // code use val
}

Type patterns could also be used within a Switch Statement. For example: 

public string EvaluateSwitchStatement(T criteria)
{
    switch (criteria)
    {
        case Int32 value : return $"Type {nameof(Int32)}, Value = {value}";
        case Int64 value: return $"Type {nameof(Int64)}, Value = {value}";
        case string value: return $"Type {nameof(String)}, Value = {value}";
        case List<int> value when value.Count < 5: return $"Type Small {nameof(List<int>)}, Value = {value}";
        case List<int> value when value.Count == 5: return $"Type Medium {nameof(List<int>)}, Value = {value}";
        case List<int> value: return $"Type Big {nameof(List<int>)}, Value = {value}";
        case null: return "Null Detected";
        default:  return $"Type Unknown";
    }
}

As one can observe, the patterns have made the switch statements whole the more powerful. However, there is a lot of boilerplate code going around. You would wish to do away with the repeated case and return/breaks.

 

Introducing Switch Expressions

 

Before we look into other patterns, it would be a good idea to introduce one of the finest features of C# 8 - the switch expressions.

The switch expression introduces a switch like syntax in the context of expression and provides a clean and concise way for writing switch when each switch arm produces a value.

Let us rewrite the switch statement in our example of type pattern using a switch expression.

public string EvaluateSwitchExpression(T criteria) => criteria switch
{
    Int32 value => $"Type {nameof(Int32)}, Value = {value}",
    Int64 value => $"Type {nameof(Int64)}, Value = {value}",
    string value => $"Type {nameof(String)}, Value = {value}",
    List<int> value when  value.Count < 5 => $"Type Small {nameof(List<int>)}, Value = {value}",
    List<int> value when value.Count == 5 =>  value => $"Type Medium {nameof(List<int>)}, Value = {value}",
    List<int> value => $"Type Big {nameof(List<int>)}, Value = {value}",
    null => "Null Detected",
    _ => $"Type Unknown"
};

As one can observe, the syntax has become leaner. You do not have to use the repeated return statements or breaks that associated with the switch statement.

 

The syntax has changed ever so slightly. The syntax now ensures the switch arms consists of:

• Pattern
• Optional Case Guard
• The => token
• Expression.

The criteria in the switch expression are known as Range Expression. The noticeable change is how the switch keyword now succeeds in the range expression.

 

The code above also introduces the discard pattern. Discard pattern - matches all expressions and is used to matching the default in switch expression. And since it matches all expression, it needs to appear at the very end of the switch expression.

 

Now that's all only one side of the story. The following patterns which were introduced in C# 8, make the switch expressions even more powerful. Let's go ahead and explore them.

 

Property Pattern

 

The property pattern enables you to check if the given value is null and match the public properties on the object. For example:

public class Foo
{
    public string FirstName {get;set;}
    public string LastName {get;set;}
}

var foo = new Foo {FirstName = "Anu", LastName="Viswan"};
if(foo is Foo {FirstName:"Anu",LastName:"Viswan"})
{
   // code
}

The property pattern allows you to check if Foo.FirstName and Foo.LastName matches the desired values. Compare this lean syntax against the conventional syntax which existed before the patterns were introduced.

if(foo is Foo && foo.FirstName=="Anu" && foo.LastName=="Viswan")
{
    // code
}

As evident from the code above, the property pattern has made the code more concise.

 

We could use the property pattern in our preceding example of switch expression to trim it down further.

public string EvaluateSwitchExpression(T criteria) => criteria switch
{
    Int32 value => $"Type {nameof(Int32)}, Value = {value}",
    Int64 value => $"Type {nameof(Int64)}, Value = {value}",
    string value => $"Type {nameof(String)}, Value = {value}",
    List<int> value when  value.Count < 5 => $"Type Small {nameof(List<int>)}, Value = {value}",
    List<int> {Count:5 }  value => $"Type Medium {nameof(List<int>)}, Value = {value}",
    List<int> value => $"Type Big {nameof(List<int>)}, Value = {value}",
    null => "Null Detected",
    _ => $"Type Unknown"
};

The highlighted expression has been made more concise, eliminating the case guard instead of using the property pattern. Let's explore one more case of property pattern where the pattern is exclusively used.

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
}

public string EvaluateSwitchExpression(Person criteria) => criteria switch
{
    { FirstName: "Anu", Age: 36 } => "FirstName and Age Matched",
    { LastName: "Viswan" } person when person.Age < 40 => "LastName With Age Less than Matched",
    { LastName: "Doe" } => "LastName Matched",
    null => "Input was null"
    _ => "Not Found"
};

We could make a small little improvement here towards writing more concise code. If your input was a non-null and one that doesn't satisfy any of the first 3 cases, then you would end up in the fallback case of discard pattern. Instead, to be more precise, you could use '{}' to denote any non-null value. Here, we're rewriting our switch with the improvement:

public string EvaluateSwitchExpression(Person criteria) => criteria switch
{
    { FirstName: "Anu", Age: 36 } => "FirstName and Age Matched",
    { LastName: "Viswan" } person when person.Age < 40 => "LastName With Age Less than Matched",
    { LastName: "Doe" } => "LastName Matched",
    { } => "Not Found",
    null => "Input was null"
};

The switch is still exhaustive and yet more concise.

 

Positional Pattern

 

What if as a developer, we had the option to write Deconstruct for the type Person. That would open doors for us to improve the earlier switch expression further by using the Positional Pattern.

 

Let us go ahead and write the Deconstruct for Person first before updating our switch expression.

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }
    public void Deconstruct(out string firstName, out string lastName, out int age) => (firstName, lastName, age) = (FirstName, LastName, Age);
}

Now with the Deconstruct in place, let us rewrite our switch expression using the positional pattern.

public string EvaluateSwitchExpression(Person criteria) => criteria switch
{
    ("Anu", _, 36 )=> "FirstName and Age Matched",
    (_,"Viswan",_) person when person.Age < 40 => "LastName With Age Less than Matched",
    (_,"Doe",_) => "LastName Matched",
    { } => "Not Found",
    null => "Input was null"
};

Gone are the property names which were required in the Property pattern. The code is even cleaner now. The positional pattern is not restricted to switch expression or switch statement, you could also use it in the regular if conditions. For example:

if(person is ("Anu","Viswan",36))
{

}

Tuple Pattern

 

If the Deconstruct could lead us to the positional pattern, then the Tuple could not be left behind either. The Tuple Pattern is a special case of a positional pattern that makes use of the Tuples.

 

The Tuple Pattern comes across as a great tool when one has multiple criteria to test. Consider the following scenario:

public string EvaluateSwitchExpression(string firstName, string lastName, int age) => (firstName, lastName, age) switch
{
    ("Anu", "Viswan", _) => "FirstName and Age Matched",
    (_, "Viswan", var a) when a < 40 => "LastName With Age Less than Matched",
    (_, "Doe", _) => "LastName Matched",
    (null, null, _) => "Input was null",
    (_, _, _) => "Not Found",
};

Summary

 

Clearly, the evolution of Pattern Matching and introduction of switch expression has made it possible to write more concise code. This evolution of the language has made it more exciting times for .NET developers in times ahead.