[Discussion] [RFC-1092] Add support for System.Half

[abelbraaksma]

This thread is meant to discuss the proposal RFC-1092, see #499.

This follows language suggestion: fsharp/fslang-suggestions#909.

Unresolved questions atm:

1. Should we add an additional numeric literal suffix?
2. How can we ensure FSharp.Core can be used with this new type in .NET 5.0, but still link to older versions?
3. Should we add overloads like half: int -> half and half: decimal -> half even though System.Half does not define them?

[abelbraaksma]

I think I can answer some:

Should we add an additional numeric literal suffix?

Currently, System.Half is implemented as a non-primitive type and uses intrinsics for special processing by the CLR. This leads to problems defining constants (a byte array init is possible, but leads to other issues like endianness). Efforts are underway to provide support for unmanaged types as constants, but not before .NET 5.0.

My verdict: don't do this.

Should we add overloads like half: int -> half and half: decimal -> half even though System.Half does not define them?

They were deliberately excluded from the runtime API proposal on the grounds that they require rounding. Since they are not in the explicit conversion operators, implementing it ourselves would undoubtedly lead to differences once the runtime catches up and provides these conversions.

My verdict: don't do this.

How can we ensure FSharp.Core can be used with this new type in .NET 5.0, but still link to older versions?

This may actually lead to us postponing this implementation. I have some ideas how we can do this painlessly without a dependency, but if the past is any indication, this may be considered a blocker.

[pblasucci]

I am, thus far, in 100% agreement with @abelbraaksma ... and I’m still “noodling” on the final point (about compatibility with < Net5).

[abelbraaksma]

@cartermp Since .NET will continue to evolve and the future will see faster increase of versions and, likely, features, we'll need some way to allow a single FSharp.Core.dll to reference stuff in new editions of .NET, while still remaining backwards compatible. This is true for System.Half, but also for ImmutableArray stuff.

I can think of several ways, but each has its drawbacks, here's a little brainstorm:

1. Ship multiple versions of FSharp.Core.dll (like FSharp.Core.net5.dll etc) and improve magic-linking to pick the right one based on project TFM.
   • Downside: hard to maintain long-term with increasing #if directives complexities
   • Unclear how to resolve multi-targeting projects with single source base
2. Create additional libs that extend FSharp.Core.dll only linked for older tfm's, like a specific System.Half.dll for netcore3.1, but absent for net5.0.
   • Upside: Easy to maintain and develop on a case-by-case basis
   • Downside: increasing set of auxiliary dlls
   • Downside: not all new functionality may be expressible in older .NET versions, esp. if its about intrinsics
3. Define a source-level mechanism to create a type alias with an internal attribute like MinimalTargetFramework("net5.0") and if another framework is targeted, any consumed function referencing this type will lead to an error or warning.
   • Upside: easy to maintain, easy to extend, can keep single lib FSharp.Core.dll
   • Works largely similar like ConditionalAttribute
   • Downside: may be relatively hard change to implement in compiler
4. Redefine the types and methods in-house from the runtime sources
   • Upside: no changes in compiler needed, can keep single lib FSharp.Core.dll
   • Downside: may conflict when linking with libs containing actual types, potential missing of intrinsic optimizations of runtime

My preference is the the 3^rd option, as, when done right, gives us a lot of freedom in implementing a proper cross-tfm FSharp.Core.dll cherry-picking optimized functions when they become available, and keeping up with new features added in the runtime. It may also be a way forward to start adding the long-awaited ImmutableArray to FSharp.Core.

[Happypig375]

So this won't happen for at least a year until FSharp.Core targets net5.0+?

[dsyme]

It's my understandng that System.Half can be used directly using the name "System.Half" plus the existing available operators and types

[dsyme]

@Happypig375 I've added a note to the RFC proposal here asking for clarification on the status-quo experience. I really believe it is likely to not be that bad, no worse than consuming any other user-defined C# numeric type from F#. Missing literals and a built-in half conversion function are likely to be the main problems, but in practice these are not significant blockers.

https://github.com/fsharp/fslang-design/pull/499/files#r501840990

[abelbraaksma]

Yeah, by now I wonder if we should drop this or not. We do have NS 2.0 and NS 2.1 for F# Core, but I don't see plans for .NET 6.0 or up on the horizon.

I know I tried to champion this proposal, unless we find some useful way to support certain future features of .NET in F# Core and the compiler (i.e. literals and sprintf placeholders), I don't quite see this happening.

[T-Gro]

Multi-targetting instead of NS would be an option for one of future releases, allowing better progressive enhancement.
It would effectively mean that library authors would need to do the same in order to benefit from it (i.e. also change from NS to multi-targeting).

For a category of library features, there was the proposal for separable Fsharp.Core.* libraries, instead of a single one.
But System.Half would likely need to get into static optimizations for basic operators, which is not a well separable concern.

[abelbraaksma]

@T-Gro, tx. Yep, there's that too. But optimizing things on compiler level, why not easily separable, is manageable. Essentially it would just be code that is triggered if it encounters a Half type in System.

Another alternative that has been done in some cases is to just copy the System.Half implementation. Of course, this means a non-optimal System.Half for people not linking to .NET 5 or above, and one may argue that it becomes harder and harder to maintain over time.

Yet another path would be to allow a single FSharp.Core to be smart about the presence of certain features. Something like an #ifexists System.Half switch that's part of the pickled info (or just an attribute) for certain functions, and the compiler will expose this accordingly (i.e., if System.Half is in scope, certain functions come into scope). Such a system would be highly flexible, but come with its own caveats.