Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Swift support #178

Open
wants to merge 86 commits into
base: experimental-record
Choose a base branch
from
Open

Add Swift support #178

wants to merge 86 commits into from

Conversation

li-feng-sc
Copy link
Contributor

@li-feng-sc li-feng-sc commented Jul 12, 2024

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>” 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
Copy link
Contributor

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

li-feng-sc and others added 3 commits July 12, 2024 14:11
When non-nullable pointers are set, externally defined
interface types were not being treated the same as file-local
interface types, causing missing import headers and incorrect
pointer types to be used in C++ generated code.
@paulocoutinhox
Copy link
Contributor

What Swift version is required?

@li-feng-sc
Copy link
Contributor Author

What Swift version is required?

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

@paulocoutinhox
Copy link
Contributor

What Swift version is required?

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

I check here, you are correct, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants