Nullness issue - type inference on pattern match for nullable values is unexpected

[isaacabraham]

Issue description

The following code triggers FS3261:

let blip =
    match true with
    | true -> null
    | false -> "test"

with blip being inferred as type string. The above should reasonably be inferred as string | null, and I believe the equivalent of the above using if / then / else does indeed do that.

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

.NET 9

Reproducible code snippet and actual behavior

let blip =
    match true with
    | true -> null
    | false -> "test"

Possible workarounds

Add a type annotation on blip e.g. blip : string | null.

[isaacabraham]

Just to add to this - I'm not sure what one might expect to see if you flip the order around - I suspect the current behaviour is correct; I wouldn't want the compiler to infer (string | null) if I accidentally return a null on a subsequent branch.

IOW, perhaps first branch should "win" when determining the nullness of an expression?

[isaacabraham]

FYI: The behavior in if then else constructs behaves exactly as what I am looking for. Pattern matching should IMHO follow that.

[T-Gro]

IOW, perhaps first branch should "win" when determining the nullness of an expression?

Yes, this should have been the case. It is a regression that it isn't.

[T-Gro]

#18015 (comment)