Native Number Support and Improvements

[praeclarum]

I propose we include support for the CLR's new native numbers and C# binding.

I propose:

1. Ensuring that explicit conversion from all of F#'s primitive types is supported
2. Support arithmetic operators
3. Support generic numeric functions (max, sqrt, etc.)
4. Perhaps, a new manifest constant suffix to designate native. (Or is this already taken up by IntPtr?)

The existing way of approaching this problem in F# is:

1. Xamarin has introduced their own native types (nint, nuint, nfloat) in the System namespace which are usable but inelegant from F# since they rely heavily on implicit conversions and some constructors are private/internal.

2. F# has native int but it is incompatible with Xamarin's current work and the CLR's future work.

Pros and Cons

The advantages of making this adjustment to F# are that F# can be used for mobile development.

The disadvantage of making this adjustment to F# is it introduces yet another numeric type, one that can be potentially confused with existing support for System.IntPtr.

Extra informtion

Estimated cost (XS, S, M, L, XL, XXL): S/M (depends on how good we make it)

If you browse Xamarin F# code for native int use, you will see the current state of the art. I think we can do better!

Here is an example of some code using it that isn't too bad: https://gist.github.com/praeclarum/c9e2d1a0f1089cb4025a

But things get much nastier if we want to support arithmetic with some constants or other variables.

let x = 42.0
let y = 3.14
let point = CGPoint (nfloat x, nfloat y) + CGPoint (nfloat 0.0, nfloat 1.0)
let angle = atan2 (float point.Y) (float point.X) |> nfloat

As you can see, F# code ends up being littered with types everywhere. In C#, this would be:

var x = 42;
var y = 3.14;
var point = new CGPoint (x, y) + new CGPoint (0, 1);
var angle = Math.Atan2 (point.Y / point.X);

Things basically go bad when you start mixing your model data (real data that is platform independent) with the data that native platforms plan to display (which is usually native sized). Problems compound when you start using native data structures (CGPoint) and try to do math with them.

Affadavit (must be submitted)

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• This is not a breaking change to the F# language design
• I would be willing to help implement and/or test this
• I or my company would be willing to help crowdfund F# Software Foundation members to work on this

[dsyme]

Thanks, I added a link to this to the CoreFX doc here: dotnet/corefxlab#1488

This can be considered approved-in-principle. You can go ahead and add an RFC for this if you like (it would be a while before I get any time to look at this)

[cloudRoutine]

@praeclarum you can define a new literal for a prototype of this using custom numeric types

[dsyme]

It seems the C#/.NET teams will be taking an erase-to-IntPtr-plus-metadata-annotations approach to this, see dotnet/corefxlab#1471 (comment)

If so this means there is very little work needed for F# here, just deciding on how export happens

If anyone spots a change in plan from this please let me know on this thread.

[enricosada]

can we add a modifier too? like for decimal?

so like:

> 10.0m ;;
val it : decimal = 10.0M

> 10.0n ;;
val it : nfloat = 10.0N
> 10n ;;
val it : nint = 10N

this avoid at least for constants

let x = 42.0
let y = 3.14
let point = CGPoint (nfloat x, nfloat y) + CGPoint (0.0n, 1.0n)
let angle = atan2 (float point.Y) (float point.X) |> nfloat

[realvictorprm]

@dsyme what's the status of this? Can we at least apply what @enricosada suggested?

[dsyme]

@realvictorprm Yes, we could apply this, but I'd need to understand the exact final status of the CLR feature

[cartermp]

cc @KrzysztofCwalina for more information about this:

Yes, we could apply this, but I'd need to understand the exact final status of the CLR feature

[dsyme]

@cartermp Looks like C# have not committed to the feature as yet https://github.com/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-05-26.md#native-ints

[cartermp]

Yeah, I think they're just all-in on getting nullable reference types working 😄

[Happypig375]

Now C# 9 is getting this. https://github.com/dotnet/csharplang/blob/b75760a72480d4214bf68d3150a2ff649c80e95e/proposals/NativeInt.md
https://sharplab.io/#v2:EYLgZgpghgLgrgJwgZwLQDlYEsBuECSAdjADQwhYA2APgAIBMABAMKMDejAxgPaHIyMAJhE5YAtlEqMIjALyMAzAG5GAXyA=