[Proposal] Support for type narrowing based on control flow analysis

[marco-carvalho]

Summary

Add support for type narrowing where the compiler automatically refines variable types based on control flow analysis, similar to TypeScript's implementation.

Motivation

Currently, C# requires explicit casting or pattern matching even when the compiler could logically infer that a type has been narrowed through control flow. This leads to verbose code and unnecessary defensive programming.

Detailed Design

The compiler should narrow types in the following scenarios:

Null checks

string? text = GetText();
if (text != null)
{
    // text should be narrowed to 'string' (non-nullable)
    Console.WriteLine(text.Length);
}

Type checks with is

object obj = GetObject();
if (obj is string)
{
    // obj should be narrowed to 'string'
    Console.WriteLine(obj.Length);
}

Benefits

1. Reduced boilerplate: Eliminates need for explicit casts in many scenarios
2. Better null safety: Makes nullable reference types more ergonomic
3. Improved developer experience: Code becomes more readable and intuitive
4. Consistency: Aligns with TypeScript's approach, familiar to many developers

Alternatives

• Continue using explicit pattern matching and casting
• Rely on nullable reference type flow analysis improvements
• Use guard clauses with throw expressions

Related Work

• TypeScript's control flow analysis and type narrowing
• Flow's type refinements
• Kotlin's smart casts

This feature would significantly improve the ergonomics of working with nullable types and polymorphic code in C#.

[CyrusNajmabadi]

I'm a bit confused. Your null check and truthiness check examples already work in the language.

[CyrusNajmabadi]

The challenge with type narrowing case (like checking if an object is string) is that it will change the meaning of existing code. For example, causing overload resolution to change with code that uses that particular variable.

[HaloFour]

I remember the conversation about type narrowing when pattern matching was first being discussed, and that it was rejected pretty quickly because it would effectively reinterpret a ton of existing code to mean something subtly different. I'm not sure if those discussions are buried on Codeplex or on the Roslyn repo somewhere, though.

[colejohnson66]

Real quick example:

IEnumerable x = ...;
if (x is IEnumerable<int>)
{
    // Currently, `y` is `IEnumerator`, but inferring per proposal would make it `IEnumerator<int>`
    var y = x.GetEnumerable();
}