Investigate whether it's beneficial to share P/Invokes with similar signatures

[rolfbjarne]

Example:

Messaging.void_objc_msgSend_IntPtr_nuint(base.Handle, Selector.GetHandle("setTitle:forState:"), intPtr, (nuint)(ulong)P_1);

P_1 is a [Native] enum, which is an n[u]int so it can have a different size on 32/64 bits architectures.
An IntPtr can also do this job and since we're already using them in many places (handles) we have a better chance to share an existing signature for objc_msg[Super]Send
e.g. void_objc_msgSend_IntPtr_IntPtr already exists

Potential:

• smaller platform assembly (minor impact)
• smaller app bundles for large apps (minor impact)

[rolfbjarne]

I wonder if we can use function signatures to completely get rid of all the overloads...

[DllImport ("libc")]
static extern void objc_msgSend ();

internal unsafe static class MessagingFunctions {
    static void *GetFunctionPointer ()
    {
        delegate* unmanaged<void> func = &objc_msgSend;
        return (void *) func;
    }
    
    static delegate* unmanaged<IntPtr> GetFunction_IntPtr ()
    {
        delegate* unmanaged<void> func = &objc_msgSend;
        return (delegate* unmanaged<IntPtr>) (void *) func;
    }
}

// and then called like:

var msgSend = MessagingFunctions.GetFunction_IntPtr ();
var handle = msgSend (this.Handle, Selector.GetHandle ("init"));

[Therzok]

I think the latter proposal will work if all CPU architectures pass return values in registers, and not on the stack.

[rolfbjarne]

We'd still need to call the right objc_msgSend[_stret|_fpret] function.