[API Proposal]: NotAllNullAttribute (or ExactlyOneNotNullAttribute)

[Bartleby2718]

Background and motivation

NotNullWhenAttribute is great. I don't need to add the null-forgiving operator (!) to suppress CS8602 Possible dereference of null in the following code:

Dictionary<int, string> d = [];
if (d.TryGetValue(1, out var value1))
{
	Console.WriteLine(value1.ToString()); // no CS8602 Possible dereference of null
}
if (!d.TryGetValue(1, out var value2)) // note the negation
{
	Console.WriteLine(value2.ToString()); // WARNING: CS8602 Possible dereference of null
}

Today, I noticed a C# class where there were two nullable reference type properties. Our business logic requires that exactly one of them were non-null. Therefore, if one of them is null, the other must be non-null. However, there is no built-in attribute to annotate this relationship at compile time.

private class MyClass
{
	public string? MyProperty1 { get; set; }
	public string? MyProperty2 { get; set; }
	public void MyMethod()
	{
		string eitherOne = this.MyProperty1 ?? this.MyProperty2; // CS8600 Converting null literal or possible null value to non-nullable type.
	}
}

I'm curious if it's possible to do this without a null-forgiving operator.

API Proposal

namespace System.Diagnostics.CodeAnalysis;

public sealed class NotAllNullAttribute : Attribute // or ExactlyOneNotNullAttribute
{
	// looks for all members with the same equivalenceKey within a class
	public NotAllNullAttribute(string equivalenceKey) // or public NotAllNullAttribute(params string[] memberNames)
}

(I think both NotAllNullAttribute and ExactlyOneNotNullAttribute will be useful.)

API Usage

private class MyClass
{
	[NotAllNullAttribute(equivalenceKey: "name")]
	public string? FirstName{ get; set; }
	[NotAllNullAttribute(equivalenceKey: "name")]
	public string? Nickname { get; set; }

	public string Name => this.FirstName ?? this.Nickname; // no CS8603

	public void MyMethod()
	{
		string name = this.FirstName ?? this.Nickname; // no CS8600
	}
}

Alternative Designs

No response

Risks

No response

[iam3yal]

@Bartleby2718

Our business logic requires that exactly one of them were non-null. Therefore, if one of them is null, the other must be non-null.

Independently to the static analysis, you state that "exactly one of them were non-null" but then your example means "at least one" so this this.FirstName ?? this.Nickname might not fulfill the requirement in practice on its own because both of them can still be non-null at the same time so in my opinion you should consider introducing a Name type as part of your domain. Something like this:

class Person
{
	public Name? FirstName{ get; set; }
    
	public Name? Nickname { get; set; }

	public Name Name => Name. FromEither(FirstName, Nickname);
}

sealed record Name
{
    private string _name { get; }

    private Name(string value)
        => _name = value;

    public static Name FromEither(
        Name? firstName, 
        Name? nickname, 
        [CallerArgumentExpression("firstName")] string? firstNameArg = null,
        [CallerArgumentExpression("nickname")] string? nicknameArg = null)
    {
        if ((firstName is not null) ^ (nickname is null))
        {
            throw new ArgumentException($"Either {firstNameArg} or {nicknameArg} must be null, but not both.");
        }

        return firstName ?? nickname!;
    }
    
    public static implicit operator Name(string value)
    {
        ArgumentException.ThrowIfNullOrEmpty(value);

        return new Name(value);
    }
    
    public override string ToString() => _name;
}

[Bartleby2718]

@iam3yal Thanks for the input! I think I used a poor example here. I think a better example would be MethodDeclarationSyntax in Roslyn.

• MethodDeclarationSyntax.Body uses a block body:
  • int MyMethod() { return 1; })
• MethodDeclarationSyntax.ExpressionBody uses an expression body
  • int MyMethod() => 1;
• Exactly one of them will be null, and tbe other will always be non-null for "regular" methods (at least for now, as of C# 12, unless the method is an abstract/extern/interface/partial method).

I'm wondering if it would be statically enforce this requirement without introducing a custom record, as this is a pretty common use case. Let me know if the motivation/suggestion makes sense!

[iam3yal]

@Bartleby2718 I can't see how this can be enforced statically.

[yaakov-h]

In your examples they are technically reachable at runtime as nothing seems to be enforcing that. I would consider something like:

string name = this.FirstName ?? this.Nickname ?? throw new System.Diagnostics.UnreachableException();