Proposal: Type narrowing methods | Method matchers - TypeScript-style Type Guards

[Hookyns]

Motivation

In recent years, the trend has shifted towards stronger type safety and combating nullability issues. In C#, we now have the nullability, along with init and required. However, I still see a gap when it comes to a higher-level feature that could significantly improve code design: TypeScript-style Type Guards.

Type Guards allow for more precise and expressive types, enabling us to refine a type based on a condition. Instead of having numerous nullable properties—some of which may or may not be null depending on the context—we could have a single base type that can be narrowed into a more specific type using a Type Guard. This approach would provide clearer constraints on what is non-nullable and what is not, resulting in cleaner and more maintainable code.

A Problem

Let's consider a simple example using a Result object:

public interface IResult {
    bool IsOk { get; protected init; }
    IReadOnlyCollection<ResultError> Errors { get; }
}

public interface IResult<TValue> {
    TValue? Value { get; }
}

In the generic IResult<TValue> interface, the Value property should be non-nullable and property Errors should be empty (or ideally, the property should not exist at all) when the IsOk property is true. Otherwise, Value should be null (or ideally, the property should not exist at all) and Errors should contains errors.

Solution With Current Features

We are able to solve this simple example with one of the special attributes like this:

public interface IResult<TValue> {
    [MemberNotNullWhen(true, "Value")] // Attribute added to specify non-nullable behavior
    new bool IsOk { get; } // we have to redeclare property as new

    TValue? Value { get; }
}

Usage

IResult<Pizza> result = _pizzaMaker.MakeQuattroFormaggi();

if (result.isOk) {
    // result.Value is narrowed to non-nullable Pizza
    DoSomethingWith(result.Value);
}

// result.Value is nullable; but it has no meaning here; that property is redundant

While these attributes work, they feel like a workaround and are not widely known or used. Additionally, they only cover a limited number of common scenarios.

Strongly-Typed Declaration

So there are no redundant properties, no nullable types.

public interface IResult {
    bool IsOk { get; protected init; }
}

public interface IResult<TValue> : IResult { }

public interface IErrorResult : IResult {
    IReadOnlyCollection<ResultError> Errors { get; }
}

public interface IErrorResult<TValue> : IErrorResult, IResult<TValue> { }

public interface IOkResult<TValue> : IResult<TValue> {
    TValue Value { get; }
}

Usage
Code written with this strongly-typed declaration can become cumbersome. It may require a significant amount of boilerplate code, especially in more complex scenarios, and forces developers to explicitly specify all types, making it far from user-friendly. As a NuGet package author, you cannot simply include this in your library; instead, you must educate your users on how to write conditions to achieve the intended results.

IResult<Pizza> result = _pizzaMaker.MakeQuattroFormaggi();

if (result is IOkResult<Pizza> okResult) { // instead of `result.IsOk`
    DoSomethingWith(okResult.Value);
}
else if (result is IErrorResult<Pizza> errorResult) { // instead of just else clause
    DoSomethingWithError(errorResult);
}

Design

I propose introducing the ability to define pattern matching directly on methods, allowing it to be utilized when calling those methods.

Method Declaration

Basic Syntax

• Variant 1 - like where constraints:

  public interface IResult<TValue> : IResult
  {
      bool Ok() match this : IOkResult<TValue>;
  }

• Variant 2 - utilizing is:

  public interface IResult<TValue> : IResult
  {
      bool Ok() match this is IOkResult<TValue>;
  }

  I think this variant is better. It is more like pattern matching.

In the match expression/specifier/whatever we can use this or a method parameter.

public static class Guards
{
    public static bool PropsNotNull(SomeType obj, X x) 
        match obj is { Prop1: not null, Prop2: not null, Prop3: not null };
}

else clause

public interface IResult<TValue> : IResult
{
    bool Ok() match this is IOkResult<TValue> else IErrorResult<TValue>;
}

Usage

I came up with two possible approaches.

• Variant 1 - "override" type of the variable in the scope

  IResult<Pizza> result = _pizzaMaker.MakeQuattroFormaggi();
  
  if (result.Ok()) {
      // `result` narrowed to IOkResult<Pizza> in this scope
      DoSomethingWith(result.Value);
  }
  else {
      // `result` narrowed to IErrorResult<Pizza> in this scope
  }

  I like this approach the most, but I doubt it has a strong chance of being accepted.

• Variant 2 - pattern matching style

  IResult<Pizza> result = _pizzaMaker.MakeQuattroFormaggi();
  
  if (result.Ok() match okResult) { // It's like `result is IOkResult<Pizza> okResult`
      DoSomethingWith(okResult.Value);
  }
  else {
      // I'm not sure how to utilize the else clause in this variant. Maybe just in switch expression..
  }

  IResult<Pizza> result = _pizzaMaker.MakeQuattroFormaggi();
  
  result.Ok() switch {
      match okResult =>  DoSomethingWith(okResult.Value),
      else errorResult => DoSomethingWithError(errorResult)
      // or like this? `_ errorResult => DoSomethingWithError(errorResult)`
  }

Notes

• The benefits are substantial when dealing with complex types that have many nullable properties.
• This could be very interesting in conjunction with the proposed Union types.
• The implementation of these methods may be optional or even forbidden. These methods should return true when a pattern matches and false otherwise. Or, during compilation, they could be removed and their calls could be replaced by the pattern from method definitions. This could simply serve as syntactic sugar, allowing for the reuse of patterns.

What do you think about this idea?

[HaloFour]

Having the data influence the typing feels like a very TypeScript approach, which works given that types don't actually exist. I don't quite see how that works with static typing in C#/.NET as the underlying type is entirely independent of the values of any of the members of the type, and it's up to constructor code to ensure that you can't get an instance of a type that violates that contract.

Pattern matching over union types is definitely being considered, but that would be based on the type hierarchy and/or the tag. So, for the suggested use case, I would expect that you could do the following:

IResult<Pizza> result = _pizzaMaker.MakeQuattroFormaggi();

result switch {
    Ok(var value) =>  DoSomethingWith(value),
    Error(var error) => DoSomethingWithError(error)
}

[Hookyns]

@HaloFour

Having the data influence the typing feels like a very TypeScript approach, which works given that types don't actually exist. I don't quite see how that works with static typing in C#/.NET as the underlying type is entirely independent of the values of any of the members of the type, and it's up to constructor code to ensure that you can't get an instance of a type that violates that contract.

That's what I meant in Notes section:

The implementation of these methods may be optional or even restricted.

I do not mention the typing there, but that's the reason, why the implementation should be "restricted"/forbidden.

In fact, I don’t have any example where writing an implementation would be beneficial. So it can be just some kind of declaration, like abstract method, delegate or event. Basically, it should be declaration for patterns, a shortcut for common pattern matching.

Dumb example:

public class SomeType
{
    public bool Completed { get; private set; }
    public string? Prop1 { get; private set; }
    public string? Prop2 { get; private set; }
    public string? Prop3 { get; private set; }

    // ... other code filling the props
}

Prop1, Prop2 and Prop3 are nullable, but when Completed is true, they will never be null.

So you can use pattern matching to exclude nulls:

var obj = new SomeType();

if (obj is { Prop1: not null, Prop2: not null, Prop3: not null }) {
    // Nulls from these properties are excluded; the type system knows it is not null in this scope
}

It is currently working like this. But you have to write that check on multiple places. It would be nice to have a method wraping that check.

public class SomeType
{
    public bool Completed { get; private set; }
    public string? Prop1 { get; private set; }
    public string? Prop2 { get; private set; }
    public string? Prop3 { get; private set; }

    public bool IsCompleted()
        match this is { Prop1: not null, Prop2: not null, Prop3: not null };
}

So compiler can replace this:

if (obj.IsCompleted()) { }

by match declaration

if (obj is { Prop1: not null, Prop2: not null, Prop3: not null }) {

And eg. this:

if (Guards.Something(args1)) { }

by

if (args1 is { Something: true }) { }

No type conversions, nothing dynamic. Just regular pattern matching. It would be on you to declare types properly so you can narrow it; As I declared the "strongly-typed" Result.

Full code of the example

.NET Fiddle example here.

using System;
using System.Collections.Generic;
using System.Linq;

public class Program
{
    private static readonly PizzaMaker _pizzaMaker = new PizzaMaker();
    
	public static void Main(string[] args)
	{
		var result = _pizzaMaker.MakeQuattroFormaggiOrder();
		
		// could be just `result.IsOk()`
		if (result is IOkResult<IReadOnlyCollection<RecycledPaperBox<Pizza>>> okResult) {
		    Console.WriteLine(okResult.Value.First().Pizza.Name);
		}
	}
}

class PizzaMaker {
    public IResult<IReadOnlyCollection<RecycledPaperBox<Pizza>>> MakeQuattroFormaggiOrder() {
        return new OkResult<IReadOnlyCollection<RecycledPaperBox<Pizza>>>(new [] {
            new RecycledPaperBox<Pizza>(new Pizza("Quattro Formaggi"))
        });
    }
}

record Pizza(string Name);

record RecycledPaperBox<TPizza>(TPizza Pizza);


public record ResultError();

public interface IResult
{
	bool IsOk { get; protected init; }

/*
	bool Error() 
	  match this is IErrorResult;
*/
}

public interface IResult<TValue> : IResult
{
/*
	bool Ok()
	  match this is IOkResult<TValue> else IErrorResult<TValue>;

	bool Error() 
	  match this is IErrorResult<TValue>;
*/
}

public interface IErrorResult : IResult
{
	IReadOnlyCollection<ResultError> Errors { get; }
}

public interface IErrorResult<TValue> : IErrorResult, IResult<TValue> { }

public interface IOkResult<TValue> : IResult<TValue>
{
	TValue Value { get; }
}

public class Result : IResult
{
	public bool IsOk { get; init; }
}

public class OkResult<TValue>(TValue value) : Result, IOkResult<TValue>
{
	public TValue Value { get; } = value;
}

public class ErrorResult(params ResultError[] errors) : Result, IErrorResult
{
	public IReadOnlyCollection<ResultError> Errors { get; } = errors;
}

public class ErrorResult<TValue>(params ResultError[] errors) : ErrorResult(errors), IErrorResult<TValue> { }

It is quite a difference to write this:

if (result is IOkResult<IReadOnlyCollection<RecycledPaperBox<Pizza>>> okResult) {
    DoSomething(okResult.Value);
}

and this

if (result.IsOk()) { // narrowed by proposed feature to `IOkResult<IReadOnlyCollection<RecycledPaperBox<Pizza>>>`
    DoSomething(result.Value);
}

/

if (result.IsOk() match okResult) { // new syntax; narrowed by proposed feature to `IOkResult<IReadOnlyCollection<RecycledPaperBox<Pizza>>>`
    DoSomething(okResult.Value);
}

[HaloFour]

So you can use pattern matching to exclude nulls:

I see, that's basically active patterns: #277

As for how they interact with NRTs, that would be orthogonal and I would expect that the same approach used to inform NRTs would continue to apply.

It is quite a difference to write this:

That's something that the discriminated unions proposal aims to solve. You don't need a completely new concept of pattern matching to make that work, you just match against the case and deconstruct into data elements as needed. I've already given you an example of what that syntax would look like and it's even less verbose than your proposal.

[Hookyns]

I see, that's basically active patterns: #277

Okay, yeah, seems like that.

That's something that the discriminated unions proposal aims to solve.

Oh, I saw your example, but I was a bit confused. I couldn't recall seeing anything like that in the Union types proposal; I read the proposal some time ago. Now, I've read the current version and yes, this is essentially what I'm missing. There is also an example with Result. 😄