[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.

[charlesroddie]

There is so much junk here, added at top level. The cost of the junk outweighs the benefits of the feature. Everything is outside of boxes. People will think toddlers have been let loose.

Two type aliases

For something extremely common, like System.Double, having a type-alias is OK. Having two type aliases, like float and double is not OK. There was obviously indecision at some point in F#'s history and the presence of two type aliases is calling out for one to be deprecated.

For something extremely rare like this, which would be public at the top level, then 0 type aliases is best. Without a type alias you can open System and use Half. The number of uses of let half = is going to be much more than the number of uses of the half type. You start typing "h" and some niche half type is going to be displayed.

Two conversion functions

Again never two, and here 0 is best since System.Half already has these functions.

Add public let binding nanh: half, compiled name NaNHalf

No this is a ludicrous level of junk. Adding nans at top level in F# was a mistake and the existing ones should be hidden (EditorBrowsable(false)?). Even if nans weren't a wart, which they are, they should be placed in a proper location as a matter of hygiene. a NanHalf is a System.Half so you expect to find it inside System.Half. Where it already is.

Add public let binding infinityh

Again. Should not be taken out of its box. I think we need a cleanup discussion before making progress with this RFC.

Add a numeric literal postfix letter, h, to allow parsing of literals as half types (open question)

Not worth it. If we are going to add another possible letter, there is more valuable in having it user-definable since there is a shortage of letters available for numeric literals.

These ones have to be done:

Make sure all arithmetic operators work when both arguments are halfs.
Make sure generic comparison for two half arguments map to Half.GreaterThan etc.

(NB this would be superseded by the generic iequatable/icomparable suggestion).

Add overloads to functions double and float
Add overloads for functions single and float32

Probably have to do this. I assume from the existence of both double and float that there is a transition from ocaml to dotnet naming which is going extremely slowly. It would be good to have a recommendation of which we want future F# code to use.