[RFC FS-1060 - Nullable Reference Types] discussion

[cartermp]

Discussion for https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1060-nullable-reference-types.md

The biggest user-facing change in the RFC is the discovery that syntax like this:

let len (str: string | null) = ...

Would be a breaking change. For example, this code is valid F# today:

let f2 (_ : string | null) = 1

And there are likely other variants of this that people could conceivably have in their code.

Thus, we are currently thinking that we will match the C# syntax:

let len (str: string?) = ...

Since it is not a source-breaking change.

[dsyme]

Would be a breaking change. For example, this code is valid F# today:

There are other examples, e.g. compare

type X = A of string | B | C

and

type X = A of string | null | C

Here the reduction to perform on | is very non-obvious in the context of Yacc LALR parsing

Requiring parenthesization may be feasible but definitely fiddly to implement

type X = A of (string | null) | C

[isaacabraham]

I don't think that this would be immediately obviously to users what the parentheses are for here, either.

[dsyme]

Other options might be

let len (str: Nullable<string>) = ... // for reference types compoiled as `string`, for value types Nullable<_>
let len (str: string or null) = ... 
let len (str: string || null) = ... 

[jamessdixon]

Do option types "None" still map to Null in C# world? And therefore Some t maps to this new Non Nullable? That would be a breaking change in many places in my code base

[cartermp]

@jamessdixon You can read about this a bit here: https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1060-nullable-reference-types.md#interaction-with-usenullastruevalue

In short, None will still map to null, and the only change we may consider doing is warning on Some null in F# code. But existing C# code that interops with F# options must still compile as it does today.

[JordanMarr]

My feedback:

I really like the "?" notation because it is concise, and I'm already used to it from C#:
let len (str: string?) = ...

Unimportant side question: would we would have to open System to use the ? notation?

If below is also valid, then does that mean we could also substitute T? anywhere we would otherwise write Nullable<T>? That would be a very welcome side benefit from this IMO.
let len (str: Nullable<string>) = ...

I really like the twist that the emitted warnings can also be tuned to emit as errors. I would definitely want that to be the case all the time, but I can understand why it might not be the default. Nice to have the option though.

[cartermp]

@JordanMarr

Would we would have to open System to use the ? notation?

No, it would have to be available without opening that namespace.

If below is also valid, then does that mean we could also substitute T? anywhere we would otherwise write Nullable<T>?

Perhaps. We're considering how to rationalize nullable reference types with nullable value types (Nullable<'T>) and if syntax and analysis can equally be applied there. Note that Nullable<string> does not compile because the 'T is restricted to structs.

[cartermp]

@dsyme We'll also need to consider nullable operators: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/nullable-operators

I think I'd discourage their usage, but it could feel weird that they didn't work with nullable reference types.

[dsyme]

@cartermp Nullable operators are primarily present for query expressions. Indeed Nullable in C# is primarily there for nulls in databases and LINQ

It may well raise lots of questions about nullability and database queries and database ORM mappers. And type providers too

[cartermp]

Yeah, I'm not keen on them being used outside of that context (lacking any data, my impression is they're rarely used already). But it'd be good to keep track of nonetheless.

[dsyme]

A note on inference subtleties...

In current F#, code such as

let f x = match x with null -> 1 | _ -> 2

places a T: null constraint on the inferred type. e.g.

> let f x = match x with null -> 1 | _ -> 2;;
val f : x:'a -> int when 'a : null

That is, in the absence of other information F# 4.5 infers a definition-site annotation on the type variable itself.

If the input type is known to have a use-site nullable annotation, then it seems reasonable to allow this:

let f (x: string?) = match x with null -> 1 | _ -> 2;;
val f : x:string? -> int

This is not so bad and is likely the behaviour we will expect, but it requires type annotations in a way that is unusual for F# code: adding the type annotation fundamentally changes what the code is about (from definition-side nullability to use-site nullability). This is somewhat consistent with how units of measure work in in F#.

Note that in a fully fledged version of a use-site nullness feature you would expect

> let f x = match x with null -> 1 | _ -> 2;;
val f : x:'a? -> int

However this would be a breaking change and in any case nullable annotation code can't be generic like this. If we did allow it (eg. in inlined code) then a type annotation would be needed:

> let inline f (x: 'T?) = match x with null -> 1 | _ -> 2;;
val f : x:'T? -> int

Indeed this should be allowed (it is compilable once 'T is known to be either a struct or a not-struct)

> let  f (x: 'T? when 'T : not struct) = match x with null -> 1 | _ -> 2;;
val f : x:'T? -> int when 'T : not struct

> let  f (x: 'T? when 'T : struct) = match x with null -> 1 | _ -> 2;;
val f : x:'T? -> int when 'T : struct

[dsyme]

A note on inference... In the prototype the following gives a warning because obj is used as the default for the otherwise-uninferred type of null

    let y0 = isNull null 

I suppose we should use obj? if the unconstrained type inference variable has a 'T : null constraint as is does in this case.

In contrast the following does not give a warning:

    let y0 = isNull (null: obj?)

[dsyme]

A note on extern declarations.... The default interpretation of extern declaration syntax in F# should perhaps be nullable. Or we must allow the explicit declaration of nullable pointers

From CompilerLocationUtils.fs with nullable checking on:

    [<DllImport("Advapi32.dll", CharSet = CharSet.Unicode, BestFitMapping = false)>]
    extern uint32 RegQueryValueExW(UIntPtr _hKey, string _lpValueName, uint32 _lpReserved, uint32 & _lpType, IntPtr _lpData, int & _lpchData);

Here is RegQueryValueExW accepting nullable strings or not?

[dsyme]

I'm currently working on compiling FSharp.Build with null checking on.

A note on box and unbox and the obj type. There is the question about whether these have their signatures updated to this:

        val unbox : value:obj? -> 'T
        val box : value:'T -> obj?
        val tryUnbox : value:obj? -> 'T option

However I actually feel that for most F# programming the type obj should always be interperted as including nulls. This type is used when reflection, casting etc. is used. Given we've thrown away type information it seems to be wrong to be trying to track nullness.

[dsyme]

Now compiling up FSharp.Compiler.Private using nullness checking prototype. Just looking at the first few messages.

Here's one example of a place where we need to consider how we will update FSharp.COre:

    type StructuredFormatDisplayAttribute =
        inherit Attribute
        new : value:string-> StructuredFormatDisplayAttribute
        member Value: string

SHould Value here be string or string? or oblivious. In the current prototype it is string i.e. non-null

[7sharp9]

Mixing optional params and nullable params with the ? in member definitions is going to lead to a lot of confusion, as in the optional syntax:

            ProvidedProperty(
                name, 
                propertyType, 
                getterCode = (fun args -> Expr.FieldGet(args.[0], field)),
                ?setterCode = blah

[cartermp]

I think I would prefer not having any kind of text-based classification of the warning here. I'd much prefer the message itself just contain the relevant information, such as a type mismatch. But I'll give this a feel with a prototype.

[dsyme]

I think I would prefer not having any kind of text-based classification of the warning here. I'd much prefer the message itself just contain the relevant information, such as a type mismatch. But I'll give this a feel with a prototype.

Yes it's partly for my own purposes right now, the /checknulls flag applies to about 5 different warnings, all labelled with that. I'm not sure if we're going to want to keep /checknulls or not at the moment it's really useful.

[boeremak]

I don't know if this is still a thing, but I just saw the talk Philip gave to NDC about this. In the talk the first question he gets is why not treat them as Option values instead of building a whole new thing.

He answers that it will be a lot of work, especially in the interop layer, and I can see that. But I just wanted to say that it really feels like a wasted opportunity to build a new thing when we already have the Option type that, for all intents and purposes, does the same thing.

Regarding the interop code, when handled a null now it will already crash right? There is just a convention that you won't be handled a null, it is not enforced. So if you treat the nullable type as an Option it would be possible to do an Option.bind on all the parameters and when a null is found it will just crash like it would do now. There are probably smarter ways of doing this, I am by no means a great programmer or anything.

As for backwards compat, these types are only in C# 8 right if I understand correctly? So they are only found in the most recent .Net versions, can't we do a version check somewhere.

I am not an expert by any means, just my 2 cents.

[cartermp]

@boeremak Implicitly treating any nullable reference type as an Option<reference-type> would mean massively breaking changes when a package adopts NRT. For example, any string you consume from a library today would now be an Option<string>. I found 14 cases of this a small (100 LoC) file in the F# tooling already; it terrifies me to think how many breaking changes that would cause for a large codebase.

Additionally, the way that the option type is compiled into .NET metadata means that it must be a nullable reference type, since it uses UseNullAsTrueValue to emit the None case as null. C# consumers must check for null. If this were to change, it would be a source breaking change for any C# consumer of F# options.

[boeremak]

@cartermp I did some more reading about the C# rationale and it seems they want to transition to a place where F# already is, namely things can't be null and have to be initialised when you use/instance them. At least that is what I got from reading this: https://devblogs.microsoft.com/dotnet/nullable-reference-types-in-csharp/

Is that correct?

Another thing, seems like quite a change especially if you keep the IL output the same. So it is purely enforced in the tooling? A string? in IL is just string. How are they doing VB.net? Or isn't that happening?

I did some more reading and these are good points:
fsharp/fslang-suggestions#577 (comment)

fsharp/fslang-suggestions#577 (comment)

And is exactly my thinking.

Edit: Another option: why not keep it the way it is, everyone already does null checks ( i hope :) ) when things come from C# and when it comes from F# it can't be null anyway and just forgo this completely? Maybe add some smarts to intellisense to say "this has been compiled in C# 8 so you probably don't need to do null checks on this".

I don't know the feasibility of this though.

One think I would really dislike is for F# to accommodate C# in a way that makes the core language cumbersome to use. I really do like the language.

Edit2: If this has already been discussed, I am sorry I just saw the talk today.

[cartermp]

I suggest reading the Motivation and Principles sections detailed here for a thorough rationale of the feature from an F# and .NET perspective: https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1060-nullable-reference-types.md#motivation

Much of the rest of the spec is concerned more with details on what needs to be done and what they design will be, but this prelude is the framing for the feature.

[GratianPlume]

Would be a breaking change. For example, this code is valid F# today:

There are other examples, e.g. compare

type X = A of string | B | C

and

type X = A of string | null | C

Here the reduction to perform on | is very non-obvious in the context of Yacc LALR parsing

Requiring parenthesization may be feasible but definitely fiddly to implement

type X = A of (string | null) | C

but I think it more forward-looking

[charlesroddie]

The indications are that F# may not support NRTs at the launch of .Net 5 and that's going to be a large problem for F# as this is the recommended timeline for libraries to adopt NRTs.

The suggestions in the RFC are good, but not all are necessary to support in V1 of this feature. It's important to get this feature to a minimal spec to reduce the effort to get V1 out.

Suggestions for cuts to the RFC / moves to a "Future" section

"Partial alignment of nullable value types and nullable reference types."

This can be cut. Value types don't need a T? syntax for NRTs to be consumable in F#. The fact that generic methods over NRTs are harder to write and require a when 'T : not struct consraint is not a big problem and it's also a problem that C# has to deal with.

Omitted NonNull in pattern matching

It is also proposed that the NonNull can be omitted for variable patterns preceded by an unqualified null pattern.

Having x nonnull in match nrt with | null -> ... | x -> ... is a convenience that can be added later. It's also a little controversial so better to wait to see initial usability feedback. Requiring | null -> ... | NonNull -> ... is OK for V1.

Null ambivalence (obliviousness)

If necessary this can be dropped from V1 since it could add a lot of complexity in implementation. Especially droppable if there is a rollout phase in F# where the feature is opt-in: early adopters can see if obliviousness causes significant difficulty.

Unresolved question: nullability warnings on a per-file basis?

This can easily be scoped out of V1.

Unresolved question: UseNullAsTrueValue

This is an F# flaw and not C#/.Net's responsibiltiy to fix. Have these type exposed as NRTs and have a migration path for Option.

[Happypig375]

I think we should adopt the same syntax as https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1092-anonymous-type-tagged-unions.md with the required parentheses like (string|null).

[chkn]

+1 .. I think this is more aligned with the F# philosophy.

It might also eliminate some hand wavy complexity by treating (string | null) as simply an anonymous union. Just like with other union types, the compiler will warn you if you don't handle all cases.

And because anonymous unions are erased to a reference type, the type (int | null) would just be erased to obj, which seems much simpler than dealing with Nullable<_> and generics and the different IL representations.

[brianrourkeboll]

(Forgive me if this has already been discussed or documented elsewhere. If it has, please direct me there.)

Question

How would the 'T | null syntax and semantics interact with the proposed (A | B | C) syntax for anonymous type-tagged unions in F# RFC-FS-1092 and the C# ad hoc unions proposal?

Syntax and backwards compatibility

Parentheses would definitely be required for anonymous union syntax on its own (cf. #339 (comment), #519 (reply in thread), etc.), since other types couldn't be special-cased in parsing like null is here.

Which of these, then, would be valid?

(A | B | C) | null

((A | B | C) | null)

(A | B | C | null)

(A | null | B | C)

Implementation and interoperability

The C# proposal for ad hoc unions, which is analogous to RFC FS-1092, suggests that null may be included in such a union by applying the standard C# postfix nullability annotation ? to the type as a whole, i.e.,

(A or B)?

This presumably means that any types inside the union cannot themselves be marked nullable — for example, a null A? and a null B? are indistinguishable at runtime.

It seems like the same would have to apply in F# as well, but there are a couple questions of implementation and interop unique to F#.

Type aliases

Would this be allowed?

type A = string | null

let f (x : (A | float | int) | null) = …

If it were allowed, would the compiler warn on unreachable match clauses?

type A = string | null

let (x : (A | float | int) | null) = null : A

match x with
| :? A -> …
| :? float -> …
| :? int -> …
| null -> … // Warn?

Presumably the compiler would already need to inspect type aliases to statically prevent something like

type A = string

let f (x : (A | string | float)) = …

Would using type aliases in such unions simply be disallowed altogether? Or maybe just aliases lacking a true runtime representation?

CompilationRepresentationFlags.UseNullAsTrueValue

How would something like this work, since unit is just null at runtime?

let f (x : (string | int | unit) | null) = …

What would happen if None were passed here, since it is also just null at runtime?

let f (x : (string | int option) | null) = …

What about this?

let f (x : (int option | unit) | null) = …

Is there some kind of trick that the compiler could use during codegen when a type in an anonymous union was marked with CompilationRepresentationFlags.UseNullAsTrueValue?

Or would the compiler simply need to disallow their participation in such unions when | null was also specified, when multiple such types were involved, etc.?

CC @T-Gro

[vzarytovskii]

There are so many things to unpack here. In short - it wasn't yet considered - how would we "interop" null discriminator into type-tagged unions (or anonymous), I think the final decision will be made when we will resurrect the PR and will need to update the RFC.

But currently, my (naive) thinking is the following:

Which of these, then, would be valid?

I wanna say, that initially we should allow (A | B | C) | null, with possibility to do A | B | C | null if all types are reference types, and require grouping if they're mixed (e.g. (int | string | null) will be invalid, and we should require int | (string | null) in case of nullable string, and int | Nullable<int> | string in case of nullable integer. My main reasoning here is that null itself is a discriminator for specific type and is invalid for value types (if that makes sense).

The C# proposal for ad hoc unions, which is analogous to RFC FS-1092, suggests that null may be included in such a union by applying the standard C# postfix nullability annotation ? to the type as a whole, i.e.,

(A or B)?

I think, as I mentioned above, initially, we might make this work (A | B | null) in case if all types are reference types (reasoning being that right now | null is invalid discriminator for value types), but then there's a whole new can of works about constraints inference for such functions/types.

Would this be allowed?

type A = string | null
let f (x : (A | float | int) | null) = …

I think it should be (except see my comment above w.r.t. grouping and (dis)allowing | null for value types), but ultimately depends of approved suggestion, if it's not, it can be extended to aliases afterwards.

If it were allowed, would the compiler warn on unreachable match clauses?

Yes. And it should be relatively easy to support.

CompilationRepresentationFlags.UseNullAsTrueValue

Those are good questions, I personally think that in the initial implementation those should be disallowed and/or special-cased.

I will be happy to discuss it verbally in Discord btw.

[brianrourkeboll]

Thanks for looking — I mainly wanted to ensure that there was some consideration of potential syntactic or runtime interactions between the two features so that we could both (1) try to avoid accidentally making a choice for the one feature that unnecessarily limits our options for the other, and (2) avoid ending up with two similar-but-subtly-different syntaxes if possible (e.g., | null doesn't currently require parens, but anonymous unions definitely would, so it's probably worth considering how they might both work together now).

But I also understand that we don't want to spend forever playing "what if" for a feature whose final design and timeline is largely out of our control and could always change.

[T-Gro]

@brianrourkeboll :

I think Vlad covered the high level answer already. Nice interplay with anonymous unions, at least on the syntactical level, was one of the reasons for picking the final syntax for nullable types - it feels like an anon. union now, from a syntax perspective at least.

The UseNullAsTrueLevel situation will be more difficult.
I think that a function could accept more types which can all be null at runtime, that will work.
The thing to be typechecked and warned against is matching on possible values - the compiler would need to warn about unreachable matches, or accept disjunctions for all possible runtime-nulls.

let myFunc ( x : ((string | null) | option<int>)) =
  match x with
  | null | :? option<int>.None -> //can only be together, since they boil down to the same runtime test
  | :? string as s -> ..
  | :? option<int>.Some i -> ..

[bugproof]

One major reason why I'll probably never adopt F# is a wide range of C# libraries that use NRTs to mark "optional" properties. F# uses Option type but it seems useless and counter-intuitive when you consume C# libraries just forcing you to use null again. There's so much pollution/inconsistency you would need to rewrite the entire library in F#. I'd rather rewrite them in Rust instead.

I think it would be interesting if NRTs could be interpreted as option by F#. But I'm not sure if that would have any drawbacks.

[smoothdeveloper]

option in F# works kind of the same as System.Nullable<T> only F# doesn't have the coalescing and type coercion aspects of C#, and it doesn't have the restriction of System.Nullable<T> which only applies to value types.

When F# will support NRT, I was considering it may be preferable to have, later on, a code generation that allows to translate option and ValueOption into NRT annotations in the IL, rather than make NRT "be interpreted as option" which I don't understand fully.

Would you mind to expand on the other reasons for never adopting F#, and which wide ranging C# libraries uses NRT?

Could you expand on your idea for F# to interpret NRT as option?

Thanks.

[bugproof]

I think if someone consumes a C# library that makes use of NRT from F# it would benefit F# users if they were treated as Option<T>. NRTs were added to C# only because there was no way to tell if a property should really be null but it doesn't do much else.

In F# there was always Option<T> type which is and will always be much better than NRT and anything C# team will come up with in the future like required keyword.

Would you mind to expand on the other reasons for never adopting F#

I find that bridge between C# -> F# too convoluted. I'd like to use Option<T> everywhere in my code base but I know it's simply impossible because there will always be some C# lib I will need to use and it will feel just like writing C# again but with a weirder syntax. If there was a way to write code without using null ever again just like Rust but .NET ecosystem that would be nice.

Yes theoretically I could make my wrappers/bindings that hide null usage and map None to null but it's too time consuming and I'd rather focus on writing code than maintaining bindings of different libs.

[cartermp]

See here for the consideration: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md#alternative-option-or-valueoption

[bugproof]

It would also be nice if F# types could be consumed from C# without a dependency on FSharp.Core. Maybe if there was a tool based on Mono.Cecil or dnLib that removes the dependency and converts Option<T> to NRT that would be great. I maintain one library that has a lot of data only classes and a lot of optional properties. If I could re-write it in F# and make it usable from both without additional dependencies it would be a win-win for everyone.

Or maybe write a tool that does the opposite? Generate F# compatible packages that convert NRT/required stuff to Option<T>. That would be interesting. Like an F# binding generator tool that could even be extended further.

Like I said the only thing that's stopping me from adopting F# in any way is there's no elegant way to make both of the languages work together in a harmonic way. I think a better tooling is needed to make it easier for people to adopt F# be it C# -> F# binding generator (fsharp-bindgen) or the other way around F# -> C# without FSharp.Core dependency so libraries could be created in F# but still be 100% compatible with C# without additional dependencies..

Even if in practice you can reference C# lib from F# and F# lib from C# the experience is horrible and I'm surprised such tools don't exist.

[En3Tho]

Why dependency on FSCore is such a problem? I don't really see much difference between referencing C# library nugget or F# library nuget. Okay, F# libs have one more dependency. Is that an issue at all?

[7sharp9]

For me it’s never been that much of an issue turning a potential null into F# friendly usage, it’s not very often and when I do encounter it it’s just a Option.ofNull etc. I suppose it depends on the domain?

…

On 21 Jun 2022, at 00:06, bugproof ***@***.***> wrote:  I think if someone consumes a C# library that makes use of NRT from F# it would benefit F# users if they were treated as Option<T>. NRTs were added to C# only because there was no way to tell if a property should really be null but it doesn't do much else. In F# there was always Option<T> type which is and will always be much better than NRT and anything C# team will come up with in the future like required keyword. Would you mind to expand on the other reasons for never adopting F# I find that bridge between C# -> F# too convoluted. I'd like to use Option<T> everywhere in my code base but I know it's simply impossible because there will always be some C# lib I will need to use and it will feel just like writing C# again but with a weirder syntax. If there was a way to write code without using null ever again just like Rust but .NET ecosystem that would be nice. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[7sharp9]

ILMerge does that.

…

Sent from my iPhone

On 25 Jun 2022, at 11:06, bugproof ***@***.***> wrote:  It would also be nice if F# types could be consumed from C# without a dependency on FSharp.Core. Maybe if there was a tool based on Mono.Cecil or dnLib that removes the dependency and converts Option<T> to NRT that would be great. I maintain one library that has a lot of data only classes and a lot of optional properties. If I could re-write it in F# and make it usable from both it would be a win-win for everyone. Or maybe write a tool that does the opposite? Generate F# compatible packages that convert NRT/required stuff to Option<T>. That would be interesting. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[ken-okabe]

To work around the issue, I did the following:

https://github.com/ken-okabe/vanfs?tab=readme-ov-file#nullable

NullableT

type NullableT<'a> =
    | Null
    | T of 'a
    member this.Value
            = match this with
            | Null -> failwith "Value is null"
            | T a -> a

let NullableT a =
    match box a with
    | :? NullableT<'a> as nullable -> nullable
    | _ -> T a

Usage

let nullable1 =
    Null

let nullable2 =
    NullableT "hello"

log nullable1
// Null
log nullable2
// T hello
log nullable2.Value
// hello

[ken-okabe]

Here is a comment on F# RFC FS-1060 - Nullable Reference Types.

The concerns I express below do not hinder or affect the implementation of Nullable or NRT itself, which is the goal of this RFC. However, they are related to and could potentially impact the RFC-ization of Introduce the ?. operator into F# #14 (@T-Gro), which is related to this RFC, and its subsequent implementation.

---

KISS principle

F# is my favorite language. I like that it's extremely versatile and practical as part of the .NET ecosystem, and that it's not as difficult for beginners as Haskell. I actually used Haskell for a while, but I got tired of the complexity, such as having to use do notation that depends on the Monad structure just to express a sequence, and the excessive use of extensions to disguise the language's own fundamentalism. I prefer the simplicity of F# as my primary development language.

Unlike object-oriented languages, the great thing about functional languages is that there are no unnecessary artificial premises like class structures. Of course, it goes without saying that I believe the excesses of Haskell's Do notation are an unnecessary burden on humans, and that ML or F# is the right landing point. In any case, I hope that F# will continue to be a simple language that is easy for beginners to approach, without unnecessary premises, as KISS principle

---

My Concern

Having said that, I have a concern that the "principle" in the RFC is an unnecessary premise and redundant, introducing complexities.

According to the proposal/suggestion: Add nullable reference types [RFC FS-1060] #577, the "Proposed Design Principles" have existed since the first Proposal comment.

At the time this first comment was made, it was before .NET metadata produced by C# 8.0 indicating when types are "with-null" in the .NET framework 5 or later, so I can imagine that some kind of clue was needed.

In fact, it is clearly stated there that:

We are currently in the process of clarifying a set of design principles to guide this feature.

Since then, there seems to be no evidence that the validity of this principle itself has been properly verified and agreed upon by the community. Nevertheless, there are mentions that the principle is "established" for unknown reason.

---

The Minimal, Objective Policy

I believe the following statement in the RFC is a clear and sufficient implementation policy for everyone. It is minimal, easy to understand, and leaves no room for objection. (KISS principle)

Metadata

Representation of nullable types in .NET Metadata

C# 8.0 will also distinguish between nullable and non-nullable constraints. This is accomplished with the same attribute.

F# will be aware of and respect this attribute, treating reference types as nullable reference types if they have this attribute. If they do not, then those reference types will be treated as non-nullable.

---

The Redundant, Subjective "Principle"

However, if we accept the policy for interoperability with the .NET Framework and its implementation as C#, all references to the Principles of RFC become redundant. In particular,

The value for F# is primarily in flowing non-nullable reference types into F# code from .NET libraries and from F# code into .NET libraries.

"The value" is pretty much subjective and depends on people, accordingly, it is not a concept that depends on the implementation of types. Whose values are these? At the very least, I do not intend to share these values.

Adding nullable annotations should not be part of routine F# programming.

This is a completely unnecessary constraint. It is up to the programmer to decide how to use the newly introduced types, and this is an unnecessary premise, as I emphasized at the beginning. And this Principle has not affected the implementation of the Nullable type itself.

F# users are typically concerned with this feature at the boundaries of their system so that they can flow non-null data into the inner parts of their system.

Same as above. Why does the F# language need to define the "concern" of the user? This is also irrelevant to the implementation of the type introduction.

This feature is useful for F# in other contexts, such as interoperability with JavaScript via Fable.

This is exactly right. It shows a positive use case, as opposed to a negative list of things not to do. This is a natural motivation for anyone to accept. What if Fable programmers are enthusiastic about using NRTs extensively in their projects? Why should this freedom be restricted?

So, these are the unnecessary premises and introducing complexities. (breaking KISS principle)

---

Complexity of the RFC Document

The "Principle" introduced seeds of complexity, which then rippled throughout the entire RFC document, ultimately resulting in an extremely convoluted and complex document.

From a broader perspective, the root of this complexity can be distilled to a single foundation:

• Attempts to confine and isolate NRTs to the system boundary with .NET Framework metadata.

If we remove this premise, all the complexity disappears.

---

Constraints on "Abnormal" Values

Introduce the ?. operator into F# #14

fsharp/fslang-suggestions#14 (comment) @dsyme states, based on this RFC Principle:

That is based on the following design principles:

1. Option has always been and remains the preferred representation of absent information in F#
2. ValueOption is a secondary preferred representation for performance purposes
3. .NET's Nullable<_> is an abnormal representation of absent information in F#
4. .NET's _ | null is an abnormal representation of absent information in F#

Design principles (1) and (2) and (4) are all strongly established and (4) is a central principle of the nullability work - it is for interop, not to become normal in F# code.

Design principle (3) is a bit weaker. There is some support for Nullable in FSharp.Core, in NullableOperators, though I will admit that was very much added only for query { ... } support when used in conjunction with .NET-generated database schema types and wrappers and I kind of now regret that support. In any case it's almost never used and Nullable<_> really isn't widely used in F# and any F# programmer would always replace it by option.

Of course, the statement is seen as reflecting the root of all complexity:

• Attempts to confine and isolate NRTs to the system boundary with .NET Framework metadata.

however, there is some substantial escalation from the RFC Principle,

Accordingly, it would also be natural that, as far as I can see in the thread, multiple members including myself have expressed concerns about his statement.

Initially, I overlooked the principles written in this NRT RFC, actually considering that they would not affect the implementation or actual user usage, but after reading his comments, that optimism no longer applies, since the type preferences are abnormal and never principles, as they are a human preference, not a programming language one.

I believe that prioritizing types and labeling them as "abnormal" is meaningless and unnecessary. It introduces needless complexity to F#. Why not treat all types equally and allow programmers to perform implicit type conversions?

This would eliminate arbitrary rules and make the language easier to learn and use for everyone.
Beginners will likely appreciate the elegance of curried functions and tuple-based n-ary functions in F#. However, they are unlikely to share the sentiment that certain types used in C# or .net framework are "abnormal."

Of course, I should be humble about my potential ignorance as I'm not following every detail. To be fair, I must mention that @dsyme has also carefully and responsibly expressed his concerns as follows:

Long term F# contributors such as @isaacabrahm are deeply concerned by this effect, and understandably. Given the "softness" of NRT checking - it is very easily subverted and only gives warnings - teams should consider carefully about normalizing the use of nullable reference types.

Nullable reference types are used in the F# compiler too, for occasional performance reasons largely. And yes, I can see in interop code there are reasons to use them.

In any case, I think we're still tuning things correctly when we say NRTs are not the preferred representation of absence of information (e.g. no string? syntax). I agree they may be used quite routinely in interop code and occasionally for performance reasons.

Are they "abnormal"? Yes, in F#-only domain logic that does no interop I would say yes.

Again, I don't have a precise grasp of everything, so I need to be careful with my statements. However, the validity of this claim should be assessed based on the results of the ongoing NRT implementation, rather than the current/legacy situation.

For instance,

In any case it's almost never used and Nullable<_> really isn't widely used in F# and any F# programmer would always replace it by option.

This is a typical argument based on a false premise. The current Nullable, without NRT, is extremely limited and not general-purpose, so programmers are simply guided to use Option, so far.. This argument does not consider that if this limitation were removed, the situation would evolve.

In other words, I suspect that the claim of Nullable types being "abnormal" due to their current immature state is a logical tautology and therefore invalid. The idea comes from the following background perspective.

Finally, The Background Perspective of Null

Finally,

F# has always taken the approach that F#-defined types do not have null as a normal value, while .NET-defined types do. This is a longstanding tension between F# programming and the .NET ecosystem. Now that .NET assemblies will contain information about non-nullability it is important that F# interpret and apply this information to further improve the soundness of F# code. Further, the presence of null-tracking in C# means nulls may start to be used more frequently.

The following is my perspective on the "F# has always taken the approach that F#-defined types do not have null as a normal value, while .NET-defined types do. This is a longstanding tension between F# programming and the .NET ecosystem."

It's a bit long, so please read it if you're interested.

Click to expand

---

There is a historical context for why null is so strongly avoided in programming:

Null pointer

Because a null pointer does not point to a meaningful object, an attempt to access the data stored at that (invalid) memory location may cause a run-time error or immediate program crash. This is the null pointer error. It is one of the most common types of software weaknesses,[1] and Tony Hoare, who introduced the concept, has referred to it as a "billion dollar mistake" .

History

In 2009, Tony Hoare stated[15] that he invented the null reference in 1965 as part of the ALGOL W language. In that 2009 reference Hoare describes his invention as a "billion-dollar mistake":

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

---

Null values have a notorious reputation in the programming world, often leading to runtime errors and unexpected behavior. In response, functional programming languages like Haskell, OCaml, and F# have adopted a different approach to value representation, favoring the Option types, represented as None | Some a in these languages, over traditional null values.

The Option types, while often perceived as complex for beginners, can be conceptualized using the analogy of lists or arrays . Consider a container structure that can either be empty, represented by [] , or contain a value, represented by [a] .The Option types introduce an extended concept:

Lists/Arrays	Option Types
[]	None
[a]	Some a

---

Appearently, the Option types can be useful, but they can also lead to unnecessarily complex structures.

---

Consider a Cell .

This can be represented by

• [0]

• Some 0

---

In a case the cell is empty,

This can be represented by

• []

• None

This system works so far.

---

However, the List or Option type can be easily nested such as:

• [[0]]

• Some (Some 0)

corresponds to:

or

• [[]]

• Some None

corresponds to:

---

What we need is not a nested Cell that is weired and meaningless but simply an empty Cell .

---

TypeScript cleverly avoids the complexity of nested Option types by employing the Nullable types instead.

Let's explore an example of a VSCode Extension that requires extracting the text from the active text editor.

vscode.window.activeTextEditor.document.getText() is the adequate API, in TypeScript.

The TypeScript compiler is issuing errors and warnings.

The problem is:

'vscode.window.activeTextEditor' is possibly 'undefined'.

In JavaScript, undefined signifies a variable that has been declared but not yet assigned a value. While both undefined and null exist in the language with slight differences, we won't delve into those details here. For our purposes, we can consider undefined to be similar to null in a general sense.

To visualize, it's like this!

Since VS Code users can close all tabs in the editor, vscode.window.activeTextEditor might become undefined .

The situation with vscode.window.activeTextEditor becoming undefined is similar to having an empty cell in a spreadsheet . Both represent the absence of a value we might expect to be present.

So, the proper type should be as below:

This is the Nullable type and what we really need.

---

In Functional Programming, everything is an expression or operation, at least, in principle.

When constructing expressions for mathematically consistent algebraic structures, it is essential to employ the correct types and their corresponding operators .

The concept of null references being a "billion-dollar mistake" stems from the lack of a well-designed null type and corresponding operators for programmers to use effectively.

In this case, we should use Optional chaining ( ?. ) operator in JavaScript(ES2020)/TypeScript

The optional chaining (?.) operator accesses an object's property or calls a function. If the object accessed or function called using this operator is undefined or null, the expression short circuits and evaluates to undefined instead of throwing an error.

Accordingly, the TypeScript code with the error should be fixed as below:

While the naming convention "optional chaining" evokes Option types, its actual behavior differs from nested Option types. Unlike Option types, which allow values to be either Some(value) or None, nullable chaining deals with values that can either be valid values or null. Therefore, "nullable chaining" might be a more accurate and descriptive name.

---

The "billion dollar mistake" associated with Null is a real issue that has caused countless problems in software development. However, it has also become a myth that perpetuates a misunderstanding: that the Null value itself is inherently evil.

The real issue with Null is not the value itself, but the lack of proper operators to work with Nullable types, as demonstrated by languages like TypeScript. The "billion dollar mistake" of Null essentially boils down to this: a failure to maintain a mathematically sound algebraic structure. In contrast, Option types were designed from the ground up with this rigor in mind.

There is no inherent superiority, inferiority, or abnormality in the mathematical structure of Nullable and Option types. The only difference is whether or not a mathematically consistent implementation has been provided.

Furthermore, it's unclear why the functional programming community didn't initially implement both:

• Non-nesting Nullable types
• Nesting-capable Option types

as equal counterparts. I don't have a definitive answer to this. However, it can likely be attributed to the strong aversion to Null itself, rather than any rational reason. This emotional response is evident in the current proposal, where the focus is on eradicating Null rather than exploring alternative solutions.

In conclusion, the "billion dollar mistake" of Null was not the Null value itself but the lack of a mathematically sound implementation. While Option types have historically been favored in functional programming, Nullable types can be equally valid with proper operators and a consistent mathematical structure.

That principle makes sense for F# because unlike many other languages F# is not totally in control of the world it lives in - it is not able to establish a perfect universe of order around it (whether mathematical or practical), and its need to interop with .NET while maintaining its own identity and methodology continually force this concept on it. Examples

When C# introduced Nullable<_> we didn't embrace it in F#, except for queries - but we must interop with it.

This design "principle" or "preference" is not based on any mathematical validity. We can therefore conclude that C# or the .NET framework, which do not have such biases, are more sound in their approach, provided that Nullable types come with the correct set of operators.

---

FAQ: Nullable Types vs. Option Types in Functional Programming

Q1: Don't Nullable types lead to NullPointerExceptions?
A: Not necessarily. While Null have historically been implemented in ways that can lead to NullPointerExceptions, many modern languages (like Kotlin and TypeScript) provide null-safe operators (e.g., ?., ??, ??=) to prevent such errors. Additionally, libraries or custom implementations can provide Option-like functionality for Nullable types, enabling safer operations on potentially null values.

Q2: Aren't Nullable types less explicit about the absence of a value?
A: In some languages, Nullable types may seem less explicit. However, languages like TypeScript define Nullable types as a union (T | null), clearly distinguishing between a value of type T and null. This makes the potential absence of a value explicit in the type system, enhancing code readability and maintainability.

Q3: Don't Option types offer a more unified API for working with optional values?
A: While Option types often come with a standardized set of higher-order functions (map, flatMap, filter), similar functions can be implemented for Nullable types as well. Many libraries provide such extensions, and you can even create your own if needed, allowing you to work with Nullable types in a functional style.

Q4: Aren't Option types better suited for functional programming due to their monadic nature?
A: Both Option types and Nullable types can equally support monadic operations from a mathematical perspective. There is no inherent advantage of one over the other in terms of their ability to form a monad structure. The perception that Option types are better suited for functional programming is largely due to historical implementation choices in functional languages, which have tended to provide more built-in support for Option types. However, with appropriate implementations, Nullable types can be just as effective in supporting functional programming paradigms and monadic operations.

Q5: Can't Option types handle errors more seamlessly than Nullable types?
A: Both Option types and Nullable types can be adapted for error handling, depending on the language and implementation. However, some languages have developed more sophisticated approaches. For example, Rust uses a Result type for error handling, which can be seen as an extension of the Nullable concept. The Result type is essentially a Nullable type where the "null" case carries a value (the error information) instead of being empty. This approach allows for explicit error types and provides methods for easy error propagation and handling. By giving meaning to the "null" case, the Result type enables more expressive and efficient error management, demonstrating how languages can evolve the Nullable concept to create powerful error handling solutions.

Conclusion
While Option types have historically been favored in functional programming, Nullable types can be used effectively with proper language features, libraries, or custom implementations. The choice between them often depends on the specific language, project conventions, and personal preferences. Both types offer ways to handle optional values and can be adapted to fit into functional programming paradigms.

[vzarytovskii]

Thanks! Good to have a separate thread for it here.

[charlesroddie]

I agree with @dsyme because:

• Having a small number of types, without multiple types that do the same thing, makes it easier to be productive. This is especially true for beginners.
• NRTs don't have the potentially universal application that (v)option types do, since they only apply to reference types. C# shares some syntax between NRTs and Nullable types, but the syntax is not completely homogenous and sometimes users need to know which is which. Therefore they cannot be a replacement for (v)option.
• On the other hand, the value that consuming NRTs gives in terms of working with dotnet libraries without getting NREs, is huge, and so the value at boundaries of F# code is huge.

I don't however agree with him that we should be deliberately harder to read and write NRTs (string | null instead of string?) just to make the feature less appealing.

[ken-okabe]

Thanks for your comment.

The following is a response corresponding to the three elements you presented:

---

The truth is Nullables and options do not do the same thing. The former does not allow nesting, while the latter does.
In many other languages, these are strictly distinguished, and combining them into a few or one type is equivalent to allowing type errors at the language implementation level, which will only cause confusion and issues instead of increasing productivity.

---

The reason why NRTs are only applicable to reference types is because that is the definition of NRTs. Nullables that apply to value types already exist in F#.
https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/nullable-value-types

• Option + vOption
• NRT + Nullalbe

Both are symmetrical structures. Originally, they should be implemented as such, but the current situation is not so because the unreasonable preference for biased types is due to misunderstanding of the concept.

---

In the first place, the premise that NRTs exist only to maintain compatibility with .NET libraries is not appropriate. As mentioned above, Option and Nullable are mathematically symmetrical, and the current situation is that Nullable has been excluded for historical reasons.

[charlesroddie]

Nullables and options do not do the same thing. The former does not allow nesting, while the latter does. In many other languages, these are strictly distinguished, and combining them into a few or one type is equivalent to allowing type errors at the language implementation level, which will only cause confusion and issues instead of increasing productivity.

'a option optionis a valid structure with use cases, but it is rare and one could make a case in a particular codebase that one should specify explicit DU types instead of using'a option option` for clarity - but that would be an analyzer not a hard block on the feature. Going to NRTs from options to get this particular limitation isn't compelling.

I don't see how 'a option option results in anything like type errors.

Option + vOption
NRT + Nullalbe

This isn't symmetric. You can use option everywhere (and voption almost everywhere - and the cases you can't are feature requests). You can't use NRTs everywhere, and you can't use Nullables everywhere. You need to know the structness of the underlying types to use them correctly. You need to use both, each at different times. You even need to map between then, e.g. if you have a Nullable<'int> and a class which takes int as a parameter and you want to map between them in the natural way. So, a lot more complex to use than using option everywhere.

[ken-okabe]

'a option optionis a valid structure with use cases, but it is rare and one could make a case in a particular codebase that one should specify explicit DU types instead of using'a option option` for clarity - but that would be an analyzer not a hard block on the feature. Going to NRTs from options to get this particular limitation isn't compelling.

There seems to be confusion in your argument.

My argument here has been consistent that Nullable and Option are different types, and we should not prioritize one over the other by misjudging one as superior, nor should we attempt to merge the inferior one into the superior one. This is not mathematically reasonable, and it will lead to surplus rules and complexity, causing confusion for humans, compilers, and implementations (exactly the problem we are facing now), so it is something to be avoided.

Your comment, "Having a small number of types, without multiple types that do the same thing, makes it easier to be productive. This is especially true for beginners," is an attempt to justify this avoidable event.

Your argument is to "hard block" the natural feature of "type independence" and force the particular limitation that we have to "go to Options from NRTs.", which is not compelling against my statements.

I don't see how 'a option option results in anything like type errors.

This is just a personal estimation or optimistic viewpoint that shouldn't have been considered due to the introduction of complexity, and safety has never been guaranteed. The point is that we shouldn't be having this kind of "maybe it's okay" discussion.

---

Option + vOption
NRT + Nullalbe

This isn't symmetric. You can use option everywhere (and voption almost everywhere - and the cases you can't are feature requests). You can't use NRTs everywhere, and you can't use Nullables everywhere. You need to know the structness of the underlying types to use them correctly. You need to use both, each at different times. You even need to map between then, e.g. if you have a Nullable<'int> and a class which takes int as a parameter and you want to map between them in the natural way.

Thank you for the accurate feedback. I also felt that I should have added that.

Mathematically, it is symmetric, and accordingly, the actual implementation should be, too. However, the current implementation is not, for the reasons I have already repeated.

So, a lot more complex to use than using option everywhere.

The reason you've felt so is simply that you were coding only with Option types everywhere, and I understand you want to reject an unfamiliar type. But please understand that Nullable types are different types, regardless of what you are used to or how you perceive them. And that does not justify forcing a new and different type into the system boundary, where the Nullable types or NRTs in the .NET framework realistically and reasonably exist.