Nullness issue - Option<string> is marked as NotNull using NullabilityInfoContext

[pchalamet]

Issue description

Looks like Option<string> in marked as NotNull when using NullabilityInfoContext. I expect it to be reported as Nullable since Option<string> for null has a null representation (UseNullAsTrueValue).

With provided snippet, I expect StringOption to be reported as Nullable, not NotNull.

StringOrNull = <null>
StringOption = None <-- this
ObjNull = <null>
ObjOrNull = <null>
StringOrNull => Nullable / Nullable
StringOption => NotNull / NotNull <-- this
ObjNull => Nullable / Nullable
ObjOrNull => Nullable / Nullable

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

macOS

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

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

.NET Runtime/SDK version

9.0.100-preview.6.24328.19

Reproducible code snippet and actual behavior

open System

open System
open System.Reflection

type MyClass(StringOrNull: string | null, StringOption: string option, ObjNull: objnull, ObjOrNull: obj | null) =
    member val StringOrNull = StringOrNull
    member val StringOption = StringOption
    member val ObjNull = ObjNull
    member val ObjOrNull = ObjOrNull

let classType = typeof<MyClass>
let ctor = classType.GetConstructors() |> Seq.exactlyOne
let paramInfos = ctor.GetParameters()

let inst = ctor.Invoke([| null; null; null; null |]) :?> MyClass
printfn "StringOrNull = %A" inst.StringOrNull
printfn "StringOption = %A" inst.StringOption
printfn "ObjNull = %A" inst.ObjNull
printfn "ObjOrNull = %A" inst.ObjOrNull

let nrtContext = NullabilityInfoContext()
for paramInfo in paramInfos do
    let nrtInfo = nrtContext.Create(paramInfo)
    let readState = nrtInfo.ReadState
    let writeState = nrtInfo.WriteState
    printfn $"{paramInfo.Name} => {readState} / {writeState}"

Possible workarounds

No response

[T-Gro]

Thanks for reporting this.
This affects in general all types that UseNullAsTrueValue.

It is safe to consider them not-null in F# understanding, but for C# consumers, they must be reported as nullable via IL metadata.
Thanks for spotting this.

[edgarfgp]

Note: This is part of the unresolved question in the RFC https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md#interaction-with-usenullastruevalue

[T-Gro]

At least for C# consumers (or NullabilityInfoContext for serializers, schema generators etc.) it must indicate that runtime value of option is potentially null.

The usage within F# (or rather, what can be improved without breaking much of existing code) is harder, I agree.

[edgarfgp]

@T-Gro Would it be possible to consider UseNullAsTrueValue attribute deprecation ?

[pchalamet]

At least for C# consumers (or NullabilityInfoContext for serializers, schema generators etc.) it must indicate that runtime value of option is potentially null.

Yes I've seen the problem with my own deserializer. I don't want to deal specifically building a given type (here option<>.None - if null is ok for a type instance, there is no problem. And null here is a perfectly valid value).

The usage within F# (or rather, what can be improved without breaking much of existing code) is harder, I agree.

There are so many attributes on f# types I would be surprised something can't be sorted out.

Between UseNullAsTrueValue and AllowNullLiteral there is a semantic distinction. Outside F# (and I include deserializers), probably we do not care. It's nullable and it's ok - it's expected to work correctly as before for UseNullAsTrueValue.

Within F#, it's not matchable with null (despite being null, for eg Option.None for RT). And this shall be ok too - and for me this shall rely on AllowNullLiteral only).

Maybe I do not understand the whole story tho 🙂

[T-Gro]

Unlikely.
Code with C#/F#/.. interop relying on IL layout of option for sure exists, and option is very central to F#.

[T-Gro]

At least for C# consumers (or NullabilityInfoContext for serializers, schema generators etc.) it must indicate that runtime value of option is potentially null.

Yes I've seen the problem with my own deserializer. I don't want to deal specifically building a given type (here option<>.None - if null is ok for a type instance, there is no problem. And null here is a perfectly valid value).

The usage within F# (or rather, what can be improved without breaking much of existing code) is harder, I agree.

There are so many attributes on f# types I would be surprised something can't be sorted out.

Between UseNullAsTrueValue and AllowNullLiteral there is a semantic distinction. Outside F# (and I include deserializers), probably we do not care. It's nullable and it's ok - it's expected to work correctly as before for UseNullAsTrueValue.

Within F#, it's not matchable with null (despite being null, for eg Option.None for RT). And this shall be ok too - and for me this shall rely on AllowNullLiteral only).

Maybe I do not understand the whole story tho 🙂

I think you are right here.
The schism exists - F# compiler tries very hard to pretend it is not null and will not be null for F# users (matching, assignment, generic constraints,..).
But for C# users, it is clearly a nullable type.

[pchalamet]

And NullableInfoContext is about the value site (param, field, event, property) - not about the type itself as a reference can always be nullable (CLR is not aware of non-null). I guess this can be annotated as nullable without compromising F# type system and obviously without changing type layout.