Proposal: Automatic null-checking for generic parameters with notnull constraint

[paulinhps]

Proposal: Automatic null-checking for generic parameters with notnull constraint

Summary

The notnull constraint for generic parameters currently only provides compile-time checking, but doesn't guarantee runtime safety against null values. This proposal suggests automatically injecting null-checking code (similar to ArgumentNullException.ThrowIfNull()) for parameters with the notnull constraint to improve runtime safety and align developer expectations with actual behavior.

Problem

The notnull constraint tells the compiler that a generic type parameter should not be nullable. However, this only affects compile-time checking. There are ways to bypass this constraint and pass null values at runtime:

1. Using the null-forgiving operator (null!)
2. Method calls from languages without null safety
3. Runtime type manipulations

Consider this example:

public interface IEventDispatcher
{
    Task PublishAsync<T>(T @event, CancellationToken cancellationToken = default)
        where T : notnull, IntegrationEvent;
}

// Later in code:
public async Task Dispatch()
{
    IntegrationEvent @event = null!; // Using null-forgiving operator
    await PublishAsync(@event); // Compiles successfully
    
    // Will likely cause NullReferenceException later in execution
    // instead of a clear ArgumentNullException
}

Despite the notnull constraint, the code compiles and would only fail at runtime with a potentially confusing NullReferenceException when the code tries to use the null value, rather than a clear ArgumentNullException indicating the problem immediately.

Proposed Solution

Enhance the C# compiler to automatically inject null-checking code at the beginning of methods that have generic parameters with the notnull constraint.

For example, given:

Task PublishAsync<T>(T @event, CancellationToken cancellationToken = default) 
    where T : notnull, IntegrationEvent;

The compiler would implicitly transform this to behave as if it were written:

Task PublishAsync<T>(T @event, CancellationToken cancellationToken = default) 
    where T : notnull, IntegrationEvent
{
    if (@event == null) throw new ArgumentNullException(nameof(@event));
    
    // Rest of the original method implementation
}

Benefits

1. Safety: Prevents hard-to-debug NullReferenceException by failing fast with clear ArgumentNullException
2. Consistency: Aligns runtime behavior with compile-time expectations
3. Reduced boilerplate: Developers no longer need to write redundant null checks for notnull parameters
4. Better developer experience: The language would match the intuitive expectation that a notnull constraint prevents null values at both compile-time and runtime

Precedents

There are precedents for compiler-injected null checks in C#:

• Required properties in records and classes throw exceptions when null values are assigned
• ASP.NET Core's minimal APIs already inject similar parameter validation code
• Other languages like Kotlin have similar features for non-null types

Potential Concerns

1. Performance impact: The additional checks could have a small performance cost
2. Implicit behavior: The C# team generally prefers explicit over implicit behaviors
3. Breaking change: Some code might rely on the current behavior (though this seems unlikely)

Compatibility

This change would be backward compatible, as it would only prevent behavior that is conceptually incorrect according to the constraint's intent.

Alternative Approaches

1. Create a separate constraint like strictnotnull that includes runtime checking
2. Make this behavior opt-in with a compiler flag
3. Document the current behavior more clearly and rely on static analysis tools

I believe the proposed automatic null-checking would be the most ergonomic and safe option that aligns with developer expectations.

Questions for Discussion

1. Would this feature be valuable enough to justify the implementation effort?
2. Are there edge cases or scenarios where this automatic behavior would be problematic?
3. Should there be a way to opt out of this behavior in specific cases?

Thank you for considering this proposal.

[HaloFour]

Required properties in records and classes throw exceptions when null values are assigned

C# doesn't insert any null checks for required properties. The compiler only forces that an assignment is made to the property, but it doesn't care what that value is.

[theunrepentantgeek]

I was going to comment on this.

Marking a property required is enforcing that the developer make a decision about what goes in the property - it can be perfectly valid for that decision to be this should be null.

I've used it this way in a couple places.
One was a RetryTimer where we wanted devs to be explicit about how retries were to be handled - but in some cases, null was used because we wanted no retries.
Another was Cache where a shared cache was in use - but for some cases, we wanted no caching, so null was appropriate.

[huoyaoyuan]

The automatic null check operator was reverted from C# 11 due to feedback: #5735