I propose we change string function to always return a non-null result

The existing way of approaching this problem in F# is non-nullness guaranteed for most cases, and typically for all normally-behaving F# code. The existing exceptions are custom types returning null out of their .ToString() and IFormattable implementations ...

Proposal: https://github.com/dotnet/fsharp/pull/17809/files

Pros and Cons

Even before this proposal, the string function already turned null on the input into an empty string in the output.
This also matches F#'s safety around nulls for F#-originated code. The possibility of user code overriding .ToString() into a null value might be considered a bug(/historical overlook) and fixed.

The advantages of making this adjustment to F# are:
Consistency, null safety.

The disadvantages of making this adjustment to F# are:
If there was code relying on the output of string being even null, this will be a breaking change for such code.

Extra information

This is the kind of code that would be affected.
Before, this code is returning null. After this suggestion, it would return "" as all other path of string function already do.

string { new obj () with override _.ToString () = null }
string { new IFormattable with override _.ToString (_, _) = null }

Estimated cost (XS, S, M, L, XL, XXL): XS

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.