Why are generics not supported with PInvoke

[Dewera]

There's been many occasions where I've had to create several overloads of PInvoke functions when there is a reference argument that changes based on another flag argument. A perfect example of this would be NtQueryInformationProcess where the traditional PVOID argument ProcessInformation can be replaced by something like a ref long or
ref PROCESS_BASIC_INFORMATION.

In an ideal world you would simply have a ref T argument. So I'm just curious as to what the limitations are regarding this and why we don't/can't have this functionality.

[acaly]

You can write a wrapper:

[DllImport("SomeLibrary")]
private static extern void SomePInvokeMethod(IntPtr ptr);

private static void GenericPInvokeMethod<T>(ref T val) where T : unmanaged
{
    fixed (T* ptr = &val)
    {
        SomePInvokeMethod((IntPtr)ptr);
    }
}

[acaly]

Also if you really don't want to manually write this wrapper method, now there is another tool that can do this automatically for you. (Although I guess you will end up with writing more code.)

[Dewera]

I understand that you can write a wrapper, I'm just curious as to what is currently limiting this from being done without a wrapper method

[acaly]

A normal PInvoke method with a wrapper works perfectly at least to me. If you really have too many, you may consider a source generator, or maybe more generally, a C++ header parser to generate C# code for you. Supporting the generic PInvoke methods like this should be unlikely to go into CoreCLR.

If you really want to ask what's the limitation, I think you should see the number beside the "Issue" tab of this repo. 🤣

[GrabYourPitchforks]

/cc @AaronRobinsonMSFT @jkoritzinsky

[AaronRobinsonMSFT]

@Dewera Great question. There are a few ways to answer this, let me offer you some.

1. A P/Invoke is designed to represent a C export and exposing them as a Generic function would be kind of confusing given C has no concept of Generics.
2. The P/Invoke system was written at a time, .NET 1.0, when Generics didn't exist. When Generics were added in .NET 2.0, it just wasn't done.
3. The P/Invoke system as it currently exists only supports a single associated IL Stub.

Is there a technical limitation to supporting this? I can't honestly think of one in the current dynamic IL Stub system - (3) is the biggest and then of course efficiently determining which IL Stub to use. It would require a non-trivial amount of work that may or may not justify the outcome - I don't personally think it would be of much benefit. I could also see a case being made that there are some metadata issues but I don't know if that would actually be a problem. Also, we would need a C# language update for defining a Generic DllImport.

The comment from @acaly, #46204 (comment), would be my recommendation if someone was after such support at present.

[am11]

C has no concept of Generics.

A little naming nitpick if I may 😄, C11 has a concept called Generic selection, which we are using at:

runtime/src/libraries/Native/Unix/System.Native/pal_process.c

Lines 575 to 579 in e98fb61

	#define LIMIT_MAX(T) _Generic(((T)0), \
	unsigned int: UINT_MAX, \
	unsigned long: ULONG_MAX, \
	long: LONG_MAX, \
	unsigned long long: ULLONG_MAX)

but true, not the same thing as Generics in .NET.

[AaronRobinsonMSFT]

A little naming nitpick if I may 😄, C11 has a concept called Generic selection

Thank you! I didn't know of this feature in C11. I will say it seems a bit clunky, but definitely helps with the math functions and I am sure many other scenarios. I am sure it was an amazing standards meeting when the design was discussed :-)