Corefxlab: Proposal for native int (nint)

[ahsonkhan]

cc @KrzysztofCwalina

[tannergooding]

This is missing context, but I'm wondering why we need nint when we already have IntPtr, which is defined as:

The IntPtr type is designed to be an integer whose size is platform-specific.

The spec also confirms this by indicating that native int maps to System.IntPtr:

[benaadams]

IntPtr doesn't have regular numeric operators like multiply on it and also it has extra methods that don't make sense for a simple numeric type like ToPointer()

[tannergooding]

Technically it does. IntPtr maps down to native int, as per the spec. The spec then defines all the operators you would expect. There is a championed language proposal (see https://github.com/dotnet/csharplang/issues/48) to expose those operators to C#.

[Drawaes]

Yeah I would say expose the operators don't make another data type it will end up adding to the confusion

[tannergooding]

I would also like to point out that Int32 also doesn't have regular numeric operators, as far as the type declaration is concernced (http://source.dot.net/#System.Private.CoreLib/src/System/Int32.cs,225942ed7b7a3252).

These are all compiler magic to output the appropriate IL opcodes.

Hence, why the C# language proposal exists to expose the operators defined by the CLI spec (although I had also created a bug on CoreFX to expose the operators directly -- https://github.com/dotnet/corefx/issues/10457).

[omariom]

IntPtr is good but does checked narrowing to int. I'd like to control it myself.
https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/IntPtr.cs#L121

[tannergooding]

@omariom, I think that the check makes sense, since it only exists on x64 platforms. If you are downcasting from a 64-bit pointer to a 32-bit value, you should be told about it (although providing an unchecked version, for when you really don't care might be useful). I would also expect that the nint type, if it existed would have the same check, for the same reason.

I have three primary arguments for keeping IntPtr:

1. it has existed since v1.0 of the spec
2. The spec clearly states that IntPtr is the native sized integer type and declares all the appropriate operators
3. Anyone who has written any interop code since v1.0 will have used IntPtr for any type that is native sized (whether handle, pointer, size_t, etc...). Making a new type just means that they may have to break back-compat to make their code simpler (just using the operators rather than casting and doing pointer arithmetic and casting back)

[benaadams]

The way that was used to get the jit to do the right thing without ifdefing all over the place in GcHandle was

#if BIT64
    using nint = System.Int64;
#else
    using nint = System.Int32;
#endif

[tannergooding]

@benaadams, does that work with AnyCPU and for arbitrary 3rd party projects or is it specific to the CoreCLR project?

[benaadams]

Ah; specific to CoreCLR.

[tannergooding]

To be clear, I do definitely want the functionality for native sized integers that I can readily use from C#, VB, F#, etc...

But I am of the opinion that getting the compilers (or even the framework) to properly expose these on the existing IntPtr and UIntPtr types is the proper way to do this (for all the above reasons, including that they "just work" with AnyCPU).

[Drawaes]

That's my line of thinking. Rather than creating a new int fix the ones that are already there.

[benaadams]

But its got not one but two caps in it... 😢

[tannergooding]

@benaadams, yes, but at that, you can add (I doubt the C# LDM would agree to add a new keyword):

C# using nint = System.IntPtr

[benaadams]

Ok 90% my objections are gone 😄

[nietras]

Hadn't seen this, but I have made https://github.com/DotNetCross/NativeInts which currently contains implementation of nint as thin wrapper around native int written in IL, it is fully functional. Still need to add nuint but should come soon. Would be happy to get feedback on this.

With this no if/else or preprocessor stuff is needed and all assemblies can be made/build without targetting a specific bitness.

Of course, it would be better if C# simply allowed all operations on IntPtr/UIntPtr as suggested.

[ahsonkhan]

Please provide feedback on the design using #1471.