[API Proposal]: Add MaybeNullIfNull attribute

[voroninp]

Background and motivation

Sometimes several parameters of the same type affect the nullability of result value.

For example, here are the methods from CollectionExtensions:

public static TValue? GetValueOrDefault<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dictionary, TKey key) =>
            dictionary.GetValueOrDefault(key, default!);

public static TValue GetValueOrDefault<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dictionary, TKey key, TValue defaultValue)
{
    if (dictionary is null)
    {
         ThrowHelper.ThrowArgumentNullException(ExceptionArgument.dictionary);
    }

    return dictionary.TryGetValue(key, out TValue? value) ? value : defaultValue;
}

Pay attention to the bang (!) operator used in the first method.

API Proposal

Now Imagine we could apply the attribute to the second method:

[return: MaybeNullIfNull(namef(defultValue)]
public static TValue GetValueOrDefault<TKey, TValue>(this IReadOnlyDictionary<TKey, TValue> dictionary, TKey key, TValue? defaultValue) // defaultValue is nullable now.
{
    if (dictionary is null)
    {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.dictionary);
    }

    return dictionary.TryGetValue(key, out TValue? value) ? value : defaultValue;
}

In this case bang operator won't be required, and compiler can infer nullability of returned value both based on the type of the dictionary and default value.

API Usage

var dict1 = new Dictionary<int, string>();
string str1 = dict1.GetValueOrDefault(1, null); // compiler emits warning/error because method can return null;
string str2 = dict1.GetValueOrDefault(1, "abc"); // compiler is happy.

var dict2 = new Dictionary<int, string?>();
string str3 = dict2.GetValueOrDefault(1, "abc"); // compiler complains.

Alternative Designs

No response

Risks

No response

[huoyaoyuan]

It is logically the same with NotNullIfNotNull, plus flipping the values to nullable.

Nullability attributes should go to https://github.com/dotnet/csharplang/discussions, because the semantic is owned by language spec.

[voroninp]

@huoyaoyuan If I get you correctly, the flipping will interfere with the nullability of the dictionary.

var dict = new Dictionary<int, string?>();
string str = dict.GetValueOrDefault(1, "abc"); // this will work, if used with [NotNullIfNotNull(nameof("defaultValue")]

[KalleOlaviNiemitalo]

Without the null-forgiving operator (SharpLab)

using System;
using System.Collections.Generic;

public static class C
{
    public static TValue1? GetValueOrDefault<TKey1, TValue1>(
        this IReadOnlyDictionary<TKey1, TValue1> dictionary,
        TKey1 key)
    {
        return dictionary.GetValueOrDefault(key, default);
    }

    public static TValue2 GetValueOrDefault<TKey2, TValue2>(
        this IReadOnlyDictionary<TKey2, TValue2> dictionary,
        TKey2 key,
        TValue2 defaultValue)
    {
        ArgumentNullException.ThrowIfNull(dictionary);

        return dictionary.TryGetValue(key, out TValue2? value) ? value : defaultValue;
    }
}

the warning is like

warning CS8620: Argument of type 'IReadOnlyDictionary<TKey1, TValue1>' cannot be used for parameter 'dictionary' of type 'IReadOnlyDictionary<TKey1, TValue1?>' in 'TValue1? C.GetValueOrDefault<TKey1, TValue1?>(IReadOnlyDictionary<TKey1, TValue1?> dictionary, TKey1 key, TValue1? defaultValue)' due to differences in the nullability of reference types.

i.e. the type of default is TValue1? and the call goes to GetValueOrDefault<TKey1, TValue1?>, so the return type of this call is already TValue1?. The warning complains about the dictionary target, rather than the default argument or the return type.

So if you want a MaybeNullIfNullAttribute on the return value to prevent the warning in this case, then the attribute will also have to affect type inference so that the call goes to GetValueOrDefault<TKey1, TValue1> instead. But I would not expect an attribute on the return value to have such an effect.

[voroninp]

It will affect type inference the same way as MaybeNull attribute affects the type of returned value. Even if by signature the result is not nullable, the compiler infers nullability.

[jeffhandley]

Closing this issue.

Nullability attributes should go to https://github.com/dotnet/csharplang/discussions, because the semantic is owned by language spec.