.NET Runtime Support for Swift Interop #93631
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
ghost
added
the
vcsjones
removed
the
needs-area-label
|
Tagging subscribers to this area: @dotnet/interop-contrib Issue DetailsBackgroundThe Swift programming language is developed primarily by Apple for use in their product lines. It is a successor to the previous official language for these platforms, Objective-C. C# has had limited Objective-C interop support for quite a while and it powers frameworks like MAUI and Xamarin Forms that run on Apple devices. Swift is now becoming the dominant language on Apple devices and eclipsing Objective-C. Many important libraries are now Swift-first or Swift-only. Objective-C binding is also becoming more difficult for these libraries. To continue to interoperate with external libraries and frameworks, C# needs to be able to interoperate directly with Swift, without going through an intermediate language. GoalsIn short, we should completely eliminate the required C/assembly sandwich that's currently required to call Swift from C# code, and potentially vice versa. In particular, neither C# nor Swift users should have to deal with lower-level system state, like registers or stack state, to call Swift from C#. Non-goalsC# and Swift are different languages with different language semantics. It is not a goal to map every construct from one language to the other. However, there are some terms in both languages that are sufficiently similar that they can be mapped to an identical semantic term in the other language. Interop should be seen as a Venn diagram where each language forms its own circle, and interop is in the (much smaller) space of equivalent terms that are shared between them. WorkThe exact scope of work is TBD. We can start to outline some basic requirements. We'll need the calling convention work (described above) in the runtime. Above the OS level we'll need a code generation strategy to generate C# bindings for Swift. An existing project to do that exists as Binding Tools for Swift. This work also needs further definition, but is out of scope of the .NET runtime itself. For the runtime we can focus on system-level interfacing. For that we will need:
|
agocke
added
the
User Story
|
@agocke Here is a list of libraries/frameworks people have asked for: https://github.com/xamarin/xamarin-macios/issues?q=is%3Aopen+is%3Aissue+label%3Arequires-swift. Most of them are Swift-only and could be used as definition of done (DoD) along with the CryptoKit. |
|
Is this PR aim to allow Swift (on Windows / Linux / macOS) to directly use dotNet 9 APIs without RemObject toolchains? |
No, this is mapping in the opposite direction, allowing .NET 9+ to call Swift APIs. |
Background
The Swift programming language is developed primarily by Apple for use in their product lines. It is a successor to the previous official language for these platforms, Objective-C. C# has had limited Objective-C interop support for quite a while and it powers frameworks like MAUI and Xamarin Forms that run on Apple devices.
Swift is now becoming the dominant language on Apple devices and eclipsing Objective-C. Many important libraries are now Swift-first or Swift-only. Objective-C binding is also becoming more difficult for these libraries. To continue to interoperate with external libraries and frameworks, C# needs to be able to interoperate directly with Swift, without going through an intermediate language.
Goals
In short, we should completely eliminate the required C/assembly sandwich that's currently required to call Swift from C# code, and potentially vice versa. In particular, neither C# nor Swift users should have to deal with lower-level system state, like registers or stack state, to call Swift from C#.
Non-goals
C# and Swift are different languages with different language semantics. It is not a goal to map every construct from one language to the other. However, there are some terms in both languages that are sufficiently similar that they can be mapped to an identical semantic term in the other language. Interop should be seen as a Venn diagram where each language forms its own circle, and interop is in the (much smaller) space of equivalent terms that are shared between them.
Work
The exact scope of work is bind the CryptoKit library with the projection tooling and runtime support. We'll need the calling convention work (described above) in the runtime. Above the OS level we'll need a code generation strategy to generate C# bindings for Swift. An existing project to do that exists as Binding Tools for Swift. This work also needs further definition, but is out of scope of the .NET runtime itself.
For the runtime we can focus on system-level interfacing. For that we will need:
SwiftSelf<T>andSwiftIndirectResultto represent Swift structs and enums in C# #100543SwiftSelf<T>frozen structsSwiftSelf<T>frozen structsIndirectReturnResultSwiftSelf<T>proposal #102079SwiftIndirectResultproposal #102082The text was updated successfully, but these errors were encountered: