Nullable Reference Types

[cartermp]

This is a draft of F# nullable reference types.

It is based primarily on the C# proposal, with additional considerations for F# based on existing behavior we have.

I expect a lot of things that are written down to change over time (i.e., a good lot of what I've written may not actually work out well, but we'll see 😄 )

[cartermp]

Linking dotnet/fsharp#3108 for posterity

[TIHan]

Notes

• Does x :? (string | null) generate a warning because the runtime type information doesn't have nullness
• information is dropped in F# quotations

Test cases

• can pass obj to obj | null
• can pass string to obj | null
• can't pass obj | null to obj

[dsyme]

Further notes:

Small interaction with type abbreviations, e.g. can you do

type S = string | null
type S2 = S | null

or

type S = string | null
let f (x: (S | null)) = ...

[dsyme]

ANother note: the syntax string | null may be tricky to implement. For example,

let f2 (_ : string | null) = 1

is valid code today because it is interpreted as a union pattern match combined with a type-annotated wildcard pattern:

let f2 ((_ : string) | null) = 1

Alternatives that look simpler to implement are

let f (x: string?) = x
let f (x: string or null) = x

and there is also the option of using

let f (x: Nullable<string>) = x

[voronoipotato]

This may be an extremely stupid thing to ask but why can't we treat possible nulls from outside things as Option? Null would be represented as None. This way we avoid the possible Option<Nullable>. If we're going to break things (and we're probably not) we might as well break them to be more consistent.

Edit: also let me know if this isn't the proper place to discuss this.

[davidglassborow]

@voronoipotato this is covered in the RFC document

[slang25]

Specifically here

[voronoipotato]

Thank you so much guys.

[auduchinok]

I'd like to bring nullability for tuples into consideration.
When tuples are coming from external non-F# code they can have null as a proper value while F# treats them as non-null values making working with them either more error-prone or not very convenient.

An example method from R# SDK I had to deal with recently:

[CanBeNull]
Tuple<IProject, TargetFrameworkId> GetProjectAndTargetFrameworkIdByOutputAssembly(FileSystemPath assemblyPath);

[cartermp]

@auduchinok For interop, an analogous situation would be like this: https://sharplab.io/#v2:EYLgZgpghgLgrgJwgZwLQDk4BstWFiAJQkiQDsBjCAFQE8AHFAGhhAEssAfAAQAYACbgEYA3AFgAUH0FCAdIThkYbALYRZAYQD2K+hwgIAygYBubKsnETJAbXRaymHHUbIAFDARwIASgC6ktwAzIIATPwa/ADekvxxgiHUcPQEADzCvEwyvAB8APz8ALJuPtGx8RXcAOz8ZNhYVhUAvpJNQA

Which is sort of like this:

[NonNullTypes(true)]
public class C
{
    [return: Nullable(new bool[] {
        true,
        false,
        false
    })]
    public Tuple<string, string> M()
    {
        return null;
    }
}

And we'd respect the nullability of the construct. I doubt we'd emit that because we don't have null as a proper value, but consumption of such a thing is considered in scope.

[dsyme]

I adjsuted the syntax to string? for now. string | null is very hard to support.

I will pull this and we can continue the discussion

[3xau1o]

@dsyme does the literal types proposal 1195, may allow for string | null where null would be a literal value type? this is the way it works on typescript unions