Nullness issue - nullable types are not automatically inferred

[Lanayx]

Issue description

I expect NRT to be inferred just like other types, but nullness information is lost when automatic infer happens

Choose one or more from the following categories of impact

• Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview).
• Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview).
• Breaking change related to older null constructs in code not using the checknulls switch.
• Breaking change related to generic code and explicit type constraints (null, not null).
• Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotations).
• C#/F# interop issue related to nullness metadata.
• Other (none of the categories above apply).

Operating System

Windows (Default)

What .NET runtime/SDK kind are you seeing the issue on

.NET SDK (.NET Core, .NET 5+)

.NET Runtime/SDK version

9.0.100-rc.1.24452.12

Reproducible code snippet and actual behavior

let f1 (x: string | null) = ""
let f2 x = f1 x // x has just type string

Possible workarounds

Specify explicit type signatures everywhere

[T-Gro]

This by design and an intentional feature implementation.
Why? Because in the opposite scenario, imagine the following code:

let f1 (x: string | null) = ""
let f2 x = 
     let y = f1 x // x was infered to be nullable string
     x.Length // suddenly, a nullness warning is returned on this line

Which is something I received many times when implementing nullness on this codebase itself for the fist time, before inference rules were changed.
There is a clear tradeoff between the two, and the decision is to make inference favour code that avoids nulls. And annotations have to be put in explicitly by users who want to allow nulls in, not vice versa.

==> This is by design.

[T-Gro]

This plays with the ideology at eliminating nullness as soon is it flows (typically via interop) into F#, not having it spread throughout F# codebase quickly.