Runtime support for Swift Interop in .NET 9

[agocke]

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:

• Calling convention design
  • Spec
  • Introduce CallConvSwift and special register types to represent the Swift ABI calling convention #95065
  • Introduce SwiftSelf<T> and SwiftIndirectResult to represent Swift structs and enums in C# #100543
• Call basic functions
  • Parse CallConvSwift in CoreCLR/NativeAOT #96707
  • Implement CoreCLR support for Swift calling convention
    • JIT: Support storing Swift error register value to SwiftError struct #98586
    • JIT: Support loading Swift self register from SwiftSelf struct #99132
    • Fix/enable SwiftInvalidCallConv tests for CoreCLR
  • Implement Mono support for Swift calling convention
    • [Tracking] Implement Mono support for Swift calling convention #94081
    • [mono] Block SIMD types in Swift interop #98429
    • [mono] Add runtime support for Swift calling convention on x64 and arm64 #94764
  • Implement UnmanagedCallersOnly support for Swift calling convention
    • JIT: Add basic support for Swift reverse pinvokes #100018
    • [mono] Implement UnmanagedCallersOnly support for Swift calling convention #100010
  • Frozen structs marshalling
    • CoreCLR VM Support
      • Implement Swift lowering algorithm in the CoreCLR type system #99438
    • NativeAOT/Crossgen2 type system support
      • Implement Swift's physical lowering pass in the managed type system #98831
      • Fix InlineArray and some other corner cases in Swift lowering #99337
    • RyuJIT support
      • JIT: Support frozen structs for Swift pinvokes #99294
      • Support frozen struct returns for Swift calls #99704
      • JIT: Add basic support for Swift reverse pinvokes #100018
      • JIT: Add support for struct returns from Swift reverse pinvokes #100091
      • JIT: Add support for frozen structs in Swift reverse pinvokes #100344
      • JIT: Add support for SwiftSelf<T> in Swift calling convention #103576
      • JIT: Add support for SwiftIndirectResult in Swift calling convention #103570
    • MonoVM support
      • Implement swift lowering algorithm in Mono's type system #99439
      • Implement support for Swift frozen structs in Mono runtime #102077
      • Add support for SwiftSelf<T> in Mono JIT and Interpreter #104171
      • Add support for SwiftIndirectResult in Mono JIT and Interpreter #104111
• Memory management
• Unit tests in .NET runtime
  • Test cases for validation of the SwiftSelf<T> proposal #102079
  • Test cases for validation of the SwiftIndirectResult proposal #102082
  • Add stress tests with generic structs
  • Add tests for structs with InlineArray attribute #107857

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 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. 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]

@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.