Expose low-level building blocks as API

[Therzok]

Steps to Reproduce

1. Try to manually bind a selector
2. Observe that the messaging API is internal
3. Bind it manually

Expected Behavior

Users of Xamarin.Mac should have some way to use the low-level APIs (maybe in some Unsafe namespace?)

That way, someone could technically write their own variation of bindings for performance improvements (avoiding marshalling between NSString <-> string for string bound APIs that have to marshal to NSString in native).

The APIs in question would be: selector constants, messaging API and Pinvoke definitions.

Actual Behavior

They're all internal/private

[rolfbjarne]

Users of Xamarin.Mac should have some way to use the low-level APIs (maybe in some Unsafe namespace?)

That way, someone could technically write their own variation of bindings for performance improvements (avoiding marshalling between NSString <-> string for string bound APIs that have to marshal to NSString in native).

The APIs in question would be: selector constants, messaging API and Pinvoke definitions.

There's no reason you can't write this code yourself, or even copy our code.

We've documented this, with some helper code you can copy: https://docs.microsoft.com/en-us/xamarin/ios/internals/objective-c-selectors#creating-your-own-signatures

They're all internal/private

There's a reason for this: there's a lot of them, and they're generated. Every function signature needs a different P/Invoke, and it ends up being a pretty big list. In the early days of MonoTouch these P/Invokes were public, but it turned out a nightmare to maintain, because as we changed implementation details, the set of generated P/Invokes changed, and suddenly we were unintentionally breaking the API, and we had to copy the missing generated P/Invokes to manually written code, and rinse and repeat for quite a few releases.

[Therzok]

Duplicating the code does not make much sense - JITing twice, different assemblies, etc. It would probably be okay to have it as a non-supported API, as in, have a way to reference that dll as a non stable impl.

[rolfbjarne]

Duplicating the code does not make much sense - JITing twice, different assemblies, etc. It would probably be okay to have it as a non-supported API, as in, have a way to reference that dll as a non stable impl.

At that point it might just as well be shipped differently (NuGet for instance).

[Therzok]

Another possible impl would be source generation similar to dotnet/pinvoke#565

[dalexsoto]

I am not sold on the idea of these being public even if they get versioned in NuGet, as @rolfbjarne mentioned things change on each release and if people get stuck or another package depends on a specific one because things changed and there are members that are no longer available but the latest SDK depends on the latest version because of new p/invokes are required it gets really hairy and painful really fast.

The source generator idea is not bad but I think at this point is not in the scope of .NET 6

[dalexsoto]

We have discussed this idea further and we all agreed on not being in the scope of the project, if you need any p/invokes these should live and be maintained in the project that needs them.