Nullness issue - nullness in signature file is not considered by implementation and vice versa

[BoundedChenn31]

Issue description

Compiler doesn't warn when parameter in signature file is marked as nullable but implementation is non-nullable. Opposite is also true - parameter in signature file can be non-nullable while parameter in implementation is.

I would expect to get a warning at least in first situation. Second case is more of "nice to have" category and reminds of FS3261: The type X does not support null.

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

Reproducible code snippet and actual behavior

Module1.fsi:

module Library1.Module1

val test1: string | null -> unit
val test2: string -> unit

Module1.fs:

module Library1.Module1

let test1 (x: string) = ()
let test2 (x: string | null) = ()

Project example

Possible workarounds

.

[T-Gro]

Thanks for the report.

One direction is in theoryOK (subsumable) - when the public API announced string string, but implementation can handle string|null - there is no risk. The opposite is much more dangerous.

A warning should still be present in both directions, the standard "signature and implementation are not compatible"..