Add ofNull and toNull to ValueOption

[marner2]

Add some helpers that allow for converting between ValueOption and nullable values without requiring that 'a be statically restrained as a nullable type. toNull will never generate ValueNone if the value is not nullable, and ofNull will throw an exception if you feed it a ValueNone when 'a is a non-nullable value.

I'm doing it unchecked currently, but I don't know of any way to match/discriminate on a type between nullable and non-nullable. I'm pretty sure you always end up with the type parameter being constrained all the way up, or not able to call constrained functions (hence why the implementation has to use boxing).

[TysonMN]

Commit 942f30e is a refactor of what you originally shared.

After posting this comment, I will force push a commit that adds the null type constraint to the toNullable function. Then the function will not throw a NullReferenceException. (Some of the test code in the previous commit will not compile.)

Can your code in your other PR that makes use of toNullable be changed to satisfy this type constraint?

[LyndonGingerich]

These changes make the build work.

[marner2]

@TysonMN The whole point of this construct is to not have the type constraint (see PR description).

It becomes ofObj and toObj with boxing with it, which isn't worth a separate construct.

The reason we need something like this is because we need to support view model getters that work with both a nullable type or a non-nullable type, and there are certain cases where we know the type will be nullable (submodel) and we need control in elmish over whether it's null or not (especially submodelwin).

[marner2]

@TysonMN also ValueOption.toNullable already exists in FSharpCore (as well as ofNullable). That's why I used ofNull and toNull

[TysonMN]

The whole point of this construct is to not have the type constraint (see PR description).

I see that now. Sorry I missed that before.

[TysonMN]

The force push I just did mostly cleans up the code. I deleted one test for Int32 since there was already a test for int (and they are the same) and added one test for Nullable<int>.

[TysonMN]

Great work on this @marner2! I am very happy with the final implementation. I think the effort we put into this PR was worth it :)