-
Notifications
You must be signed in to change notification settings - Fork 22
Description
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.