Moving forward, let's support separate .NET 5.0 target for FSharp.Core

[abelbraaksma]

Most recent and current 4.7.x RTM release of FSharp.Core we've had two targets: .NET Framework 4.5 and NetStandard 2.0. This is now dropped in favor of NetStandard 2.0.

However, .NET 5.0 is around the corner and replaces the NetStandard system by having only one .NET for all platforms moving forward. .NET 5.0 gives us a host of new possibilities, like System.Half intrinsics (n/a prior to NET 5.0), ImmutableArray (not in NetStandard), the Span and related types (not in NetStandard 2.0, but in 2.1) etc.

And, important for F#, having a .NET 5.0 target will allow further optimizations like utilizing SkipLocalsInitAttribute in specific tight FSharp.Core places (see also this comment: dotnet/runtime#454 (comment)).

I realize this request may be contentious as we just recently decided to remove the NetFx target in favor of a single NetStandard 2.0 one, but requiring all code to run in NetStandard 2.0 limits our possibilities moving forward, so I hope to find support to reopen this discussion. Technically it's an easy change, though we'll need to be willing to also carry the burden of having and maintaining #if NET50-like code in specific locations in FSharp.Core.

For background, I proposed some alternative approaches here which might prevent having two separate targets (fsharp/fslang-design#500 (comment), as follow-up to @cartermp's reply to the PR-RFC for System.Half), but to be honest, I don't really like any of them. Some discussion of whether there's an alternative way to use future types without multi-targeting can be found in this SO question. Bottom line: there are none.

More info on MS's policy of versioning NetStandard/.NET Core/.NET 5.0: https://visualstudiomagazine.com/articles/2020/09/16/net-standard-future.aspx

[cartermp]

I think we are quite reluctant to maintain a bunch of #if NET50 code. It wouldn't be hard for things like supporting a type alias for System.Half, but it does get significantly more difficult if we want to use things like Span<'T> inside various routines, or expose entire APIs like so: https://github.com/Horusiath/fsharp.core.extensions/blob/master/src/FSharp.Core.Extensions/Memory.fs

The reality is that the vast majority of F# code will be targeting .NET Core and .NET framework until at least a year from now, because .NET 5 is not an LTS release. I expect that larger organizations will only try it out in some newer projects given this.

[KevinRansom]

@abelbraaksma it has taken us years to get to one fsharp.core. While the desktop framework is still a thing, we will want to support netstandard2.0. Once we can drop desktop framework targeting, we will like move to an FSharp.Core that versions along side the framework. Until then netstandard2.0 will likely be our pick. the desktop framework represents our past. Your suggestion is great, but slightly premature.

[abelbraaksma]

I expect that larger organizations will only try it out in some newer projects given this.

@cartermp Yes, but that's probably true for most new features (I work for an organization that's still on .NET 4.5...).

I wasn't aware that .NET 5.0 is not an LTM, which I understand means it'll only be supported up until the next three months from the last release. Still, .NET Framework is due to be supported until at least end of 2029 (tied with Windows releases), which we cover by sticking to NETStandard 2.0. However, I hope this doesn't mean sticking to NS 2.0 that long.

Once we can drop desktop framework targeting, we will like move to an FSharp.Core that versions along side the framework.

@KevinRansom Given the above, I wonder what the cut-off point will be. I understand the "slightly premature" comment. Perhaps .NET 6.0 is a better target for my suggestion. Or perhaps we can devise a different way by using a specific attribute and metadata on functions to allow cross-compiling for NS 2.0 and .NET 5.0+ with a single source and a single binary release. Though arguably that would be a worse solution than having two targets...

Are there any other ways we can conjure up that are (1) easy to maintain (2) allows usage of future APIs or .NET (3) works in single assembly?

[cartermp]

We don't have any kind of cutoff right now. Since FSharp.Core is so central to all F# usage, it will necessarily be one of the slowest parts of the .NET ecosystem to update and drop support for things.

[KevinRansom]

I'm going to close this. For at least the next 12 months FSharp.Core is going to be netstandard 2.0.

[abelbraaksma]

I understand the decision, though I regret that this means we won't be able to move forward in terms of performance and features introduced by .NET 5 and Core 3.1 like span, skip init locals, half type etc.

[KevinRansom]

@abelbraaksma reach and simplicity wins the argument for now.

[abelbraaksma]

FWIW, we do have a NetStandard 2.0 and a NetStandard 2.1 now. Anyway, in hindsight, I don't agree with my own suggestions anymore (even though I do like to have certain new primitives made available, like Half and Int128. Maybe I'll take it on as an extension lib 🤔).

One of the motivating examples were support for SkipLocalsInit, which has since been implemented (fsharp/fslang-suggestions#990 and #11267).

Changing from "completed" to "not planned".