NRT inference

[Lanayx]

This discussion is a continuation of ticket #17738 (since ticket has been promptly closed). I've noticed that NRT inference works differently from normal type inference:

let f1 (x: string | null) = ""
let f2 x = f1 x // x has just type string

It is worth mentioning that NRTs only don't survive function argument inference, they are preserved across bindings and nested types.

The argument of this decision was "the ideology at eliminating nullness as soon is it flows", but I don't see why nullness shoud be eliminated as soon as possible. From my POV there is nothing wrong to have nullables live though the application if needed, this is especially valid for strings, since null is valid for string value in all kinds of places: protocols, databases, interop with other languages. I also don't see anything wrong with NRT explicitly appearing in my code rather than have implicit conversions through function boundaries.

So, I'd like to see the community view on this issue, whether we should keep implicit nullable to non-nullable conversion or not in auto-derivation cases.

[vzarytovskii]

there is nothing wrong to have nullables live though the application if needed

This was specifically one of the non-goals of the feature - do not encourage people to use nullables as a replacement for option types. Nulls are alien to F# code base, they should remain explicitly annotated and should not pollute the whole code base as the flow in the few places (and if we were to enable inference for them everywhere, they will spread quite quickly for the majority of the code base).

Also: the first answer really puts "at all costs" in your mouth, which is not fair. We should then rephrase the second one to "No, we should avoid accidental nulls in code base at all costs"

[Lanayx]

This was specifically one of the non-goals of the feature - do not encourage people to use nullables as a replacement for option types.

Yes, I understand the intention, however if nullables fit the use case well (which happens quite often in my experience, example), people will use it and language shouldn't put a spoke in wheel in that case.

[T-Gro]

I think this needs a little more perspective on what the opposite would be:

The nullness inference starts with a variable value for the nullness until it encounters a usage (such as value used as a parameter into a null-qualified call) with a specified nullness.

In practical terms, nullness gets inferred with the first nullness-qualified usage.

The feature implementation was like that initially, but it is very common to start functions with a call that allows nulls:

• File.Exists ...
• logInfo ...
• Activity.Start ...

The massive downside was: All the code below it in the same scope had to work with a possibly null value (since it was inferred by this first call), and warnings were raised. In order to fix the warning, the parameter value had to be annonated to be non-nullable.

It does not fit the design goal that a null-avoiding F# codebase would have to start using annotations, especially when their code was correct and null-safe before.

(btw. I just realized I voted wrong before making sure I understand the wording used . The second option should have minus 1, and the first +1)

[dsyme]

Yes this is a good summary.

Combining the nullness-flexibility with generalization process of HM type inference is not, in my eyes, an achievable goal - or at least is not the priority here.

If you want to use nullness types throughout your F# code, then you will need to annotate your argument types.