Discussion: Improve C# to F# interoperability

[eiriktsarpalis]

I'm starting this issue to discuss potential changes that could improve C# to F# interoperability.
F# to C# interoperability works fine, but anyone who's ever used an F# library API from C# might have come across some of the following issues:

Optional parameters

Adding optional parameters to F# methods:

type Foo =
    static member Bar(?x : int) = ...

introduces an implicit dependency on F# option types:

using Microsoft.FSharp.Core;

Foo.Bar(x: FSharpOption<int>.None); // use default parameter
Foo.Bar(x: FSharpOption<int>.Some(42)); // override the parameter

this can be extremely off-putting for a non-F# user, and it gets worse as the number of optional parameters increases. The situation can be somewhat improved using this technique, but it still is a tedious exercise to decorate all possible optional parameters in your public api with proper attributes. Even if this is done correctly, overridden parameters would still have to be wrapped in Some.

Here are a few potential fixes:

• Have the F# compiler automatically attach the Optional and DefaultValue attributes to every optional parameter it encounters. I believe that this does not introduce any backward compatibility issues.
• Implement a "CompatibleOptional" attribute to be attached to arguments and/or method definitions. This would tell the F# compiler to attach the Optional and DefaultValue attributes to the parameters and potentially expose the parameters in a non-F# option representation: perhaps nullable for value types and null for classes.
• We could perhaps sweeten the pill without making radical changes: add an FSharp.Compat namespace in FSharp.Core which implements helper methods for easily creating/wrapping values in F# option. Here's an example of how it could be done.

Lambda parameters

Public F# APIs that expose lambda parameters are virtually impossible to consume from other languages: users have to explicitly define a class that inherits FSharpFunc<_,_> which is extremely prohibitive.

Here are a few potential solutions:

• Add an FSharp.Compat namespace in FSharp.Core which implements helper methods for wrapping common delegate types in F# functions. Here's an example of how it could be done.
• Might be too far-fetched, but perhaps we could convince the roslyn team have lambda literals target F# funcs?

Conclusion

Please add any other interop issues that you might have come across. I firmly believe that the aforementioned issues seriously hurt widespread .NET adoption of good F# libraries. We can do much better than that.

[rojepp]

This seems a noble cause.

Have the F# compiler automatically attach the Optional and DefaultValue attributes to every optional parameter it encounters. I believe that this does not introduce any backward compatibility issues.

Wouldn't this break existing C# to F# 'interopers'? If someone has explicitly passed in a FSharpOption<int> from C#, and these attributes are added, wouldn't that be breakage?
The function now expects (from C#) an int or nothing, but gets an option.

[eiriktsarpalis]

@rojepp the attributes do not change the method's signature, they merely allow for optional attributes to be omitted. If somebody passed all arguments in correct order, it would still work as before.

[dsyme]

@eiriktsarpalis I think this could made directly into an RFC - doing work in this area would be great.

There may also be a set of op_Implicit or op_Explicit conversions that can help things from C#?

[eiriktsarpalis]

@dsyme Implicit converters are enticing, however it looks like they do not work well with lambda literals. Using the System.Converter implicit converter we see that

Converter<int, int> func = x => x + 1;
FSharpFunc<int, int> fsfunc = func;

works as expected, however

FSharpFunc<int, int> func = x => x + 1;

complains with

(1,29): error CS1660: Cannot convert lambda expression to type 'FSharpFunc<int, int>' because it is not a delegate type

[dsyme]

@eiriktsarpalis Yeah it would be ideal if that worked. Perhaps add a Roslyn issue about it - Mads might actually do this.

BTW is that with adding actual op_Implicit definitions to the FSharpFunc type?

[eiriktsarpalis]

@dsyme looks like it https://github.com/Microsoft/visualfsharp/blob/65b178e13805410f27bed0679f6f2889868b6c96/src/fsharp/FSharp.Core/prim-types.fsi#L1513

[dsyme]

@eiriktsarpalis Oh yes, I forgot we had those already.

[eiriktsarpalis]

@dsyme So you're saying we should ask the roslyn guys to enable implicit conversions for lambda literals? Or just support F# funcs?

[eiriktsarpalis]

Btw, I just picked up from the internets that this also works but it looks a bit confusing:

FSharpFunc<int, int> func = (Converter<int,int>)(x => x + 1);

[dsyme]

@eiriktsarpalis It would be up to the C# designers. This may be one instance of a more general problem they are encountering elsewhere (i.e. things that are lambda-like but aren't delegates).

[dsyme]

@eiriktsarpalis Of course preparing a PR to roslyn would help enormously.

[isaacabraham]

Maybe single method interfaces like Java 8 has ;-)

---

From: Don Symemailto:notifications@github.com
Sent: ‎10/‎06/‎2016 17:36
To: Microsoft/visualfsharpmailto:visualfsharp@noreply.github.com
Subject: Re: [Microsoft/visualfsharp] Discussion: Improve C# to F# interoperability (#1254)

@eiriktsarpalis It would be up to the C# designers. This may be one instance of a more general problem they are encountering elsewhere (i.e. things that are lambda-like but aren't delegates).

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1254 (comment)

[smoothdeveloper]

It would be nice to have [<Extension>] added automatically to a class/module if it contains a member with it defined. And it also should define it automatically on the assembly otherwise VB.NET won't find the extension methods.