ghost
commented
1 year ago Tagging subscribers to this area: @dotnet/interop-contrib See info in area-owners.md if you want to be subscribed.
Issue Details
# Background The [Swift](https://developer.apple.com/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 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](https://github.com/xamarin/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: - [ ] Calling convention design - [ ] Spec - [ ] Scenarios - [ ] Call basic functions - [ ] Tuples - [ ] Errors - [ ] Existential containers - [ ] Struct/class marshalling - [ ] Unit tests in .NET runtime - [ ] Integration tests or in-product usage (in runtime?) - [ ] CryptoKit?
| Author: | agocke |
|---|---|
| Assignees: | - |
| Labels: | `area-System.Runtime.InteropServices`, `area-Interop-coreclr` |
| Milestone: | 9.0.0 |
kotlarmilos
ShikiSuen
filipnavara
jkoritzinsky
Felix-Dev
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: