make some of FSharp.Core consumable idiomatically to dotnet code

[smoothdeveloper]

Will efforts be spent to make consuming some of the stuff from FSharp.Core more palatable in vanilla C# codebase?

I’m referring mostly to FSharpOption and FSharpFunc.

Bringing it because in mixed codebases, I end up using a mix of FSharpx.Extras, some custom extensions, stuff from FSharp.Core, it ends up being messy; especially with how poorly C# handles symbol conflicts.

The guidelines (don’t expose those types to .net consumer, and add facades/wrappers) ultimately feels more like the work on making those types integrate fluently in .net codebases has not been done, and not all code from mixed codebases can adhere to the ideals of the guidelines.

This type of impedance mismatch is also, I believe, responsible for a part of resent some of the “C# == .net” crowd may have with F#, overall hindering F# and .net.

Ideally, FSharp.Core should come fully equipped to make the most basic scenarios not look too ugly.

It is not something that is easily solvable, but worth addressing, and worth getting insight from BCL & C# teams as to how to better address.

[charlesroddie]

Is it possible to compile non-curried functions as Func<'a,'b> instead of FSharpFunc<'a,'b>?

Many current FSharpOption cases can be moved to NRTs (#6804) (everything except Option<Option<'a>> I believe, which is rare).

The names (e.g. FSharpValueOption instead of FSharp.ValueOption) I agree are inconvenient.

[smoothdeveloper]

Overall, my request is more about improving consumption / production of widespread types from FSharp.Core from other CLI languages standpoint than changing how those types or concepts are turned into in F# compiler; maybe because it is something I can more easily reason about than semantics in the compiler and non breaking change going the other way.

Also, I'm challenging the motives around design guidelines advocating for the need of "wrappers" around F# APIs for the reason of those two main types (for now) being surfaced.

Is it possible to compile non-curried functions as Func<'a,'b> instead of FSharpFunc<'a,'b>?

Curious if it is more desirable to change the compiler, than say making those two implicitly convertible from C#/VB.NET (AFAIK, they both support implicit conversion operator).

If I understand correctly, calling into FSharpFunc is more efficient than into a delegate.

Many current FSharpOption cases can be moved to NRTs (#6804)

With lots of the F# code that ships as libraries that will need to remain compatible with later versions of the language without a recompile, I suspect such move would incur lots of considerations around backward compatbility.

On the other hand, I'm all for the NRT to become idiomatic in F# codebases, and having local option types being elided the same way tuples can be.

The NRT feature hasn't shipped yet and we haven't seen F# code starting leveraging it.

The names (e.g. FSharpValueOption instead of FSharp.ValueOption) I agree are inconvenient.

I'm not concerned by those names, most of the places they'd be exposed would be in types embedding those from F# authored libraries, those embedding types would be the names most likely to show in consuming code and you could "dot your way" (or "infer your way" for local values) to the option or func values.

[wallymathieu]

I think this suggestion makes sense. We have some bridge code in https://github.com/fsprojects/FSharpx.Extras/blob/master/src/FSharpx.Extras/CSharpCompat.fs that helps you consume F# in C#. It would be nice to have some of these native in F# Core and hidden from regular F#.