Add Swift support

[li-feng-sc]

This adds first class Swift support without going through ObjC bridge.

New command line switches

• --swift-out The Swift code output directory.
• --swift-module The Swift module name. This is used to generate “import” statements that references this module.
• --swiftxx-out The C++ bridge code output directory.
• swiftxx-include-cpp-prefix The prefix for #includes of the main header files from Swift C++ files
• swiftxx-base-lib-include-prefix Swift C++ interop support library relative path
• --ident-swiftxx-class The naming convention of generated C++ bridge classes. For example, “SwiftFooBar”.
• --ident-swiftxx-file The naming convention of generated C++ files. For example, “SwiftFooBar”.

The generated code

The generated code in the output directories has 3 parts:

• Swift API These are “*.swift” files without “+Private” suffix under the output directory specified by “--swift-out”. They contain Swift definitions for Djinni enums, records, and interfaces.
• Swift bridge These are “*+Private.swift” files in the same directory as Swift API module files specified by “--swift-out”. They contain:
  • The code responsible for converting Swift objects to/from an intermediate form
  • Proxy classes that implements the protocols defined in the API module
• C++ bridge These are “.h” and “.cpp” files under the output directory specified by “--swiftxx-out”. They contain:
  • The code responsible for converting the intermediate form to/from C++ objects.
  • C++ helper functions used by the Swift proxy classes that forward Swift method calls to C++ implementations.

Notable improvements over ObjC bridge

• Djinni records are Swift structs instead of classes. This means most data can be allocated on the stack instead of heap, and without the overhead of reference counting.
• Djinni interfaces are always Swift protocols. This gives user code more flexibility in how they would implement the interfaces with classes.
• There is no boxing needed for composite types. Elements get to retain their precise type signature and a lot less objects need to be created on the heap when passing containers across the boundary.
• Correct nullability attributes are retained in nested types. “list<optional<T>>” now intuitively maps to “[T?]”.
• Maps “future<>” to a Swift type that supports the Swift "await" syntax.
• Pure Swift implementation simplifies integration with Swift code.

[paulocoutinhox]

o.o it has support for Swift direct call C++?

[paulocoutinhox]

What Swift version is required?

[li-feng-sc]

What Swift version is required?

5.9+ i think as it uses the c++ interop

[paulocoutinhox]

What Swift version is required?

5.9+ i think as it uses the c++ interop

I check here, you are correct, thanks.