Operators should be exposed for `System.IntPtr` and `System.UIntPtr`

[tannergooding]

Issue:
The CLR supports a set of operators for the System.IntPtr and System.UIntPtr types (native int). These operators can be seen in III.1.5 of the Command Language Infrastructure specification. However, these operators are not supported by some languages (such as C#).

Workaround:
Either directly emit IL or write non-optimal code that does not directly translate to the appropriate IL instructions.

Request::
A set of 'friendly operators' should be provided for languages that do not support the full set of operators for System.IntPtr and System.UIntPtr. These operators are: Add, Divide, Multiply, Remainder, Subtract, Negate, Equals, Compare, And, Not, Or, XOr, ShiftLeft, ShiftRight.

[tannergooding]

I have also logged an issue in Roslyn: dotnet/roslyn#12836, in hopes for actual language support.

[jkotas]

Related to https://github.com/dotnet/coreclr/issues/963#issuecomment-113562193

[tannergooding]

@mellinoe Should I provide a more formal specification for the APIs that are being requested?

Given that C# doesn't support these, they will need to be implemented in IL. It is likely that they should be marked with NonVersionable.

There is also the remaining question of whether these methods should be implemented as:

• actual operators in the System.IntPtr and System.UIntPtr structs
• friendly operators in the System.IntPtr and System.UIntPtr structs
• static methods in some helper class

If one of the first two, do we have an existing mechanism for performing an ilmerge to ensure that the operators exist in the runtime package.

[shmuelie]

This should work full speed and requires no changes to the CLR or C#:

static class IntPtrExtensions
{
    private static readonly Func<IntPtr, IntPtr, IntPtr> IntPtr_op_Addition_IntPtrIntPtr;

    static IntPtrExtensions()
    {
        DynamicMethod addDy = new DynamicMethod("op_Addition", typeof(IntPtr), new Type[] { typeof(IntPtr), typeof(IntPtr) });
        ILGenerator il = addDy.GetILGenerator();
        il.Emit(OpCodes.Ldarg_0);
        il.Emit(OpCodes.Ldarg_1);
        il.Emit(OpCodes.Add);
        il.Emit(OpCodes.Ret);
        IntPtr_op_Addition_IntPtrIntPtr = (Func<IntPtr, IntPtr, IntPtr>)addDy.CreateDelegate(typeof(Func<IntPtr, IntPtr, IntPtr>));
    }

    public static IntPtr Add(this IntPtr left, IntPtr right) => IntPtr_op_Addition_IntPtrIntPtr(left, right);
}

[tannergooding]

@SamuelEnglard. That is a possible workaround.

However,it requires some (possibly expensive) startup and it will not be inlined (thus requiring every operation on a 'primitive' CLR type to incur the cost of a delegate call).

[shmuelie]

@tannergooding Those are good points. The idea was that it's a cross between implementing purely in managed and having to modify the CLR.

[AlexGhiondea]

It sounds like we want a formal API proposal.

We should also consider the implementation details on this (maybe it is worth making this change in S.P.CoreLib/CoreCLR instead of having to rely on dynamically generated code for this).

[tannergooding]

Closing this as it will be getting handled in some other manner (currently it is expected to be handled via partial erasure in the C# compiler).

[karelz]

@tannergooding just curious if there is a link to Roslyn issue ...

[tannergooding]

@karelz, dotnet/csharplang#435 and dotnet/corefxlab#1471.

There are currently two proposed ways of going about it. Either partial erasure, which just makes the IntPtr type work as expected by exposing the operators via the language itself (this would be achieved via partial erasure). It could also be completed by creating an entirely new type (System.IntN), last I heard (@jaredpar might be able to provide more details), going the partial erasure route was the current preferred approach, due to a number of reasons.

[karelz]

Thanks! No details needed - just links to the master issues which are likely going to address the problem .. thanks!