[Discussion] Generate C# bindings for SwiftUI framework about runtimelab HOT 4 OPEN

Associated type doesn't have direct mapping in C# and could be represented with generics:

The prevalent opinion in previous discussions has been that mapping of protocols and associated types to C# is going to be hard. Where is the catch?

Nit:

public struct Never
{
	private Never() {}
}

This fails to compile with "The parameterless struct constructor must be 'public'.".

from runtimelab.

This issue has been updated with a better-defined goal -- feel free to provide feedback on the general direction or identified projections.

from runtimelab.

The prevalent opinion in previous discussions has been that mapping of protocols and associated types to C# is going to be hard. Where is the catch?

My understanding is that some scenarios would be harder to implement than others. Let's start with simple scenarios first.

Generic methods are used in the CryptoKit and SwiftUI dev templates. For these, we need to pass an implicit metadata pointer for the concrete type that can be located and exposed as PInvoke during binding process.

Generic methods with protocol constraints require an implicit protocol witness table parameter for conformance. There are two ways to retrieve them: statically and dynamically. Protocol conformance records are emitted in __TEXT.__swift5_proto binary section and each record contains a pointer to protocol descriptor and protocol witness table. One option is to scan it and map them to a hash table during the binding process. Alternatively, they can be retrieved at runtime using swift_conformsToProtocol. Here is an interesting article on performance of protocol conformances scanning during app startup: https://medium.com/geekculture/the-surprising-cost-of-protocol-conformances-in-swift-dfa5db15ac0c.

Methods with protocols used as types - instead of passing C# interface pointers within the projection tooling, we need to pass a boxed existential container. We need to implement their construction within the projection tooling, probably at runtime, which will depend on protocol witness tables retrieval.

An addition to above-mentioned scenarios could be types with generics, which require passing concrete type metadata and calling swift_instantiateConcreteTypeFromMangledName to create a concrete type.

For protocols with associated types, I haven't yet encountered differences in public API and underlying calling convention. I may be missing something here. This is a brief overview of these scenarios, and I will initiate the design on protocols while keeping this issue open for further requirements collection.

from runtimelab.

I agree that we should be always able to setup the right arguments and call the method. I am more worried about the projected API surface that we expose to user when protocols and generics are in the mix. Is the C# code that people end up writing against the projected API surface going to look reasonable?

from runtimelab.