Type inference handles null and default for reference types differently

[TessenR]

Version Used:

Branch master (10 Mar 2020)
Latest commit 441c154 by msftbot[bot]:
Merge pull request #42303 from CyrusNajmabadi/useCompoundParens

Support parenthesized expressions in use-compound-operator.

Steps to Reproduce:

Compile the following code

#nullable enable
class C
{
  void M(string s)
  {
    Infer(s, default); // Infer<string?>, no warnings
    Infer(s, null); // Infer<string>, CS8625 cannot convert null literal to non-nullable refernece type
  }

  T Infer<T>(T t1, T t2) => t1 ?? t2;
}

Expected Behavior:
The same type argument is inferred for both Infer calls.

Actual Behavior:
Different nullability is inferred for calls with default and null. defualt infers string? and doesn't have any warnings while the call with null infers string and reports CS8625 cannot convert null literal to non-nullable refernece type

/cc @jcouv

[jcouv]

I've not been able to make progress on this due to other work. I'll leave it open if someone could pick it up.

[RikkiGibson]

Interestingly, it seems that use of default produces undesired warnings in some scenarios, while use of null produces undesired warnings in other scenarios.

[TessenR]

Interestingly, it seems that use of default produces undesired warnings in some scenarios, while use of null produces undesired warnings in other scenarios.

Note that now default and null values in optional arguments also contribute to inferred nullability.
It created yet another inconsistency with null which seems to be a collateral of this issue - type inference changes based on whether you specified the argument explicitly or not

#nullable enable
class C<T> where T: class
{
    void M(T t1, T t2 = null) { }
    
    void Test1(T t) => M(t); // no warnings
    void Test2(T t) => M(t, null); // CS8625
}