[RFC FS-1075] - Interop with nullable-typed method parameters

[cartermp]

Starting discussion on this since it doesn't exist. https://github.com/fsharp/fslang-design/blob/master/FSharp-5.0/FS-1075-nullable-interop.md

https://github.com/dotnet/corefxlab/issues/2812 brings up an interesting problem. There may be a strong desire to apply functions like exp on a nullable value type even though the underlying method call has no nullable overload.

[dsyme]

Just to mention this one isn't actually in "preview" yet but is in the "preview" folder

[cartermp]

Strange. It's associated with the preview flaw here: https://github.com/dotnet/fsharp/blob/master/src/fsharp/LanguageFeatures.fs#L68

Is there some bug where it's just not getting actived?

[dsyme]

Just to mention this one isn't actually in "preview" yet but is in the "preview" folder

Weird, why did I even write this? Of course it's in preview.

[cartermp]

Actually, it does work and I just forgot to put in preview as the langversion

[cartermp]

Apparently it doesn't work as I'd expect it:

Using Microsoft.Data.Analysis package:

open Microsoft.Data.Analysis

let f () =
    let dateTimes = PrimitiveDataFrameColumn<DateTime>("DateTimes")

    // The following line fails to compile
    dateTimes.Append(DateTime.Parse("2019/01/01"))

    // I need to still cast to `Nullable`
    dateTimes.Append(Nullable<DateTime>(DateTime.Parse("2019/01/01")))

[cartermp]

Additionally, this kind of got me:

open Microsoft.Data.Analysis

let f () =
    let ints = PrimitiveDataFrameColumn<int>("Ints", int64 3) // Makes a column of Length 3. Filles with nulls initially.
    let strings = StringDataFrameColumn("Strings", int64 3)
    
    // Need to call `Nullable 100` instead of 100
    ints.[int64 1] <- Nullable 100
    strings.[int64 1] <- "Foo!"

I don't have a good sense for how comment something like the setting operation will be in Microsoft.Data.Analysis in normal analytical code, but having to be that explicit does feel kind of annoying to me

[dsyme]

Apparently it doesn't work as I'd expect it:

I believe it is because the argument is not actually optional, hence the T --> Nullable is not automatic under the RFC:

        public void Append(T? value)

See the last bullet of the RFC:

Should we apply this rule to all Nullable-typed arguments on methods, not just optional ones, giving a value-to-Nullable rule at method calls?

This is out of scope of this RFC

I would presume the same thing applies here:

ints.[int64 1] <- Nullable 100

Would you like me to open another RFC on this? Or look at adjusting the design of this one?

[cartermp]

Yeah, I think scoping it to include any nullable-typed arguments should be considered, especially since there's already an example of an API that doesn't consistently use optional parameters for things.

The implied Nullable 100 bit might be worth considering too, though this was less an "I didn't expect that!" and more a "ugh, that's right, I have to do that" sort of thing.

[krauthaufen]

Hey, I just recently stumbled upon an issue that could possibly be resolved by this.
When using attributes defined in C# that have a constructor with default arguments they implicitly get Nullable (like other default arguments) but F# disallows constructing nullables on attribute level. I couldn't figure out a way to pass the default argument at all. So my question is: will this solve that problem too, is there some workaround i missed or should I create an issue for that?

[NinoFloris]

Thanks for this and dotnet/fsharp#9316, they are very welcome additions!

[dsyme]

When using attributes defined in C# that have a constructor with default arguments they implicitly get Nullable (like other default arguments) but F# disallows constructing nullables on attribute level. I couldn't figure out a way to pass the default argument at all. So my question is: will this solve that problem too, is there some workaround i missed or should I create an issue for that?

This does sound like a related issue and should really be dealt with as part of this RFC. I'l endeavour to add testing for that.

[cartermp]

The first pain point I noticed is now addressed and available in VSCode and Jupyter notebooks:

[dsyme]

The first pain point I noticed is now addressed and available in VSCode and Jupyter notebooks:

That's great

[cartermp]

Any thoughts on allowing null (which is not a proper value for DateTime) to be passed as input?

let c = SomeCSharpClass()
c.TakingNullableDateTime(null) // fails to compile, null is not a proper value

Need to construct it explicitly today:

let c = SomeCSharpClass()
let x = Nullable<DateTime>()
c.TakingNullableDateTime(x) // this works

I don't feel very strongly about this but it does feel sorta like a completeness thing? I guess this is a different interaction in the type system though

[cartermp]

Another completeness thing: method parameters vs. function parameters. Since this is primarily about interop, there's no support for the following:

open System

let f (dt: Nullable<DateTime>) = ()
f DateTime.Now

Should it be supported?

[isaacabraham]

I had starting writing a whole list of reasons why this feature shouldn't be adopted, only to realise halfway through that this is already supported for option for F# methods - so would I be correct in saying that this, in effect, is just about bringing parity between F# optionals and C# nullables for consumption of optional method parameters?

One question is this change only about consumption of existing optional methods, typically from C# code - it wouldn't impact existing F# code i.e. the following code would remain as is?

type Foo() =
    member _.Foo(?v:int) = () // v is int option, NOT int Nullable.

[cartermp]

Yes, this change is backwards compatible. There are no changes to existing semantics around F#-defined optional parameters - that would be orthogonal to this feature:

[dsyme]

Another completeness thing: method parameters vs. function parameters.

We don't do any of the type-directed conversions at function calls and don't support optional arguments for those either, so no, it shouldn't be supported unless we change to do all of them.

[cartermp]

How do you feel about setters for properties? I revisited this one and felt like it would be nice to not have to convert here:

open Microsoft.Data.Analysis

let f () =
    let ints = PrimitiveDataFrameColumn<int>("Ints", int64 3) // Makes a column of Length 3. Filles with nulls initially.
    let strings = StringDataFrameColumn("Strings", int64 3)
    
    // Need to call `Nullable 100` instead of 100
    ints.[int64 1] <- Nullable 100
    strings.[int64 1] <- "Foo!"

I think it fits with the interop motivation, which is why I've felt it was okay. But I won't shed many tears if it's not considered.

[dsyme]

How do you feel about setters for properties? I revisited this one and felt like it would be nice to not have to convert here:

Hmmmm I'm surprised that doesn't work. I thought the conversion would apply as this is the value parameter for the setter.

We should look into this one.

[cartermp]

Oh dang, looks like it does. I just wasn't using an updated kernel in .NET Interactive.

#r "nuget: Microsoft.Data.Analysis"

open Microsoft.Data.Analysis

let f () =
    let ints = PrimitiveDataFrameColumn<int>("Ints", int64 3) // Makes a column of Length 3. Filles with nulls initially.
    let strings = StringDataFrameColumn("Strings", int64 3)
    
    // Need to call `Nullable 100` instead of 100
    ints.[int64 1] <- 100
    strings.[int64 1] <- "Foo!"
    printfn "Done!"

f()

prints "Done!".

[dsyme]

Excellent, thanks for checking :-)

[cartermp]

Okay, some things to update the RFC on:

• Applied for any parameter to a method, not just optional ones
• Setters are a part of this
• Rules explicitly do not apple to F# function parameters

[isaacabraham]

I like having parity in a sense with optional parameters in F# i.e. member _.Foo(?bar:Customer). I'm not so fond of applying this to property setters as well. It's just the word Nullable that you need at the start and IMHO is much more consistent with the rest of the language i.e. no implicit conversions done in the background.

[cartermp]

@isaacabraham Note that it's not just property setters as in the example, but also property initializes in constructors:

open System

type C() =
    member val P1: Nullable<int> = Nullable 1 with get, set

let c1 = C()
let c2 = C(P1 = 3)

In this case, it looks as if it's a named/optional argument application even though it's not (a similarity that is definitely intentional). I think it's perfectly natural and in alignment with the feature to do this.

[isaacabraham]

Does this already work for Options as well? Ideally (perfect world) there would be a consistent story around implicit wrapping behaviour of Options and Nullables.

[cartermp]

No, this is specifically for nullable value types only. The two are orthogonal features from a usage standpoint. Nullable is used almost exclusively for interop with a database or a .NET API that similarly needs to efficiently represent a value type that may not exist. There aren't other features built around nullable value types to make explicitness a feature, like there are for optional. Relaxing this restriction just makes interop with these components feel a bit smoother.