WIP: [ios] Enable cpp - swift interop #10004

Draft

kirylkaveryn wants to merge 3 commits from ios/enable-cpp-swift-interop into master

kirylkaveryn commented

2025-01-04 18:24:30 +00:00

Member

This is an experimental attempt to implement a new apples swift/cpp interop.

Should not be merged!

Requirements and Limitations according to the doc:

Minimum Swift Version

Swift 5.9

Minimum Xcode Version

Xcode 15.0.x (to support the Swift 5.9)

Minimum Deployment Version for Mixed-Language Application

C++ interoperability does not impose additional deployment version requirements for your application, except when your Swift code uses C++ classes or structures that become reference types.

Mapping C++ Types to Swift Reference Types

Platform running Swift application	Minimum deployment version
macOS	13.3
iOS	16.4

Without mapping to the ref we can use the basic approach, because there is no reason pass the c++ objects as a ref to the swift code.

C++ Structures and Classes are Value Types by Default

[!info]
Swift maps C++ structures and classes to Swift struct types by default. Swift considers them to be value types. This means that they’re always copied when they’re passed around in your Swift code.

The special members of a C++ structure or class type are used by Swift when it needs to perform a copy of a value or dispose of a value when it goes out of scope. If the C++ type has a copy constructor, Swift will use it when a value of such type is copied in Swift. And if the C++ type has a destructor, Swift will call the destructor when a Swift value of such type is destroyed.

C++ structures and classes with a deleted copy constructor are represented as non-copyable Swift types (~Copyable). If a C++ type has a valid copy constructor, it is still possible to make it non-copyable in Swift by annotating it with a SWIFT_NONCOPYABLE macro.

Some C++ types are always passed around using a pointer or a reference in C++. As such it might not make sense to map them to value types in Swift. These types can be annotated in C++ to instruct the Swift compiler to map them to reference types in Swift instead.

Issues and Cons:

The simulator in Xcode 16.2 cannot compile the cpp interop with error:

:0: error: compiling for iOS 12.0, but module 'Cxx' has a minimum deployment target of iOS 16.0: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/Cxx.swiftmodule/arm64-apple-ios-simulator.swiftmodule

The app can only be built on the Device or on the Xcode 15.

Swift uses C++ types and calls C++ functions directly, without any kind of indirection or wrapping but Swift maps C++ structures and classes to Swift struct types by default (This statement refers to how Swift represents C++ structs and classes internally.) This is why this structs cannot be used in the ObjC, because it works only with the NSObject types and primitives. The compile will make an attempt to import this types into the BridgingHeader.h and fails.
C++ types may be used in the ObjC using the include directive only for the internal usage, but the flow: C++ -> Swift -> ObjC -> C++ is not acceptable.
There may be some compile errors that I failed to resolve:
!Pasted image 20250103141849.png
According to the documentation swift imports the cpp code as a module. For this purposes modulemap file should be created in the every framework. It is used to expose the cpp headers to the swift compiler. The modulemap compiles only the headers that it includes and do not compiles with the includes.
It works for the cpp headers that have only a few logic /includes like the gps_track_collection or elevation_info:

compiles and visible for Swift:

module map {
  header "elevation_info.hpp"
  header "gps_track_collection.hpp"
  export *
}

This modulemap compiles but Swift still doesn't see the class bookmark at all (no error found):

module map {
  header "bookmark.hpp"
  export *
}

This modulemap does NOT compile at all:

module map {
  header "framework.hpp" // too complex to compile
  header "bookmark.hpp"
  header "track.hpp"

  header "elevation_info.hpp"
  header "gps_track_collection.hpp"
  export *
}

with error:
__memory/allocator_traits.h:305:5: error: no matching function for call to '__construct_at'

Conclusion

At first glance, the idea to use the swift/cpp interop looks nice. But our cpp frameworks (map, kml, drape...) have extremely high coupling and cannot be used separately. This is why it seems impossible for the swift compiler to generate internal structures (that are exposed to the swift) for all of the entities that are used in the .hpp files (look at the map/framework.hpp).

The second big issue is that the autogenerated swift structures cannot be used in the objective. It doesn't allow to use
the cpp structs in a way: cpp -> swift -> objc -> cpp because objc doesn't support swift structs. Only the cpp -> swift -> cpp flow is accepted or our old approach with objc wrappers.

But this feature still can be used for the small isolated frameworks that are not depends on the each other.
For example GpsTrackInfo cpp struct can easily be used to pass around the Swift codebase (but not objc).

This is an experimental attempt to implement a new [apples swift/cpp interop](https://www.swift.org/documentation/cxx-interop/#using-c-types-and-functions-in-swift). Should not be merged! ## Requirements and Limitations according to the doc: ### Minimum Swift Version Swift 5.9 ### Minimum Xcode Version Xcode 15.0.x (to support the Swift 5.9) ### Minimum Deployment Version for Mixed-Language Application C++ interoperability **does not** impose additional deployment version requirements for your application, **except** when your Swift code uses [C++ classes or structures that become reference types](https://www.swift.org/documentation/cxx-interop/status/#minimum-deployment-version-for-reference-types-imported-from-c). [Mapping C++ Types to Swift Reference Types](https://www.swift.org/documentation/cxx-interop/#mapping-c-types-to-swift-reference-types) | Platform running Swift application | Minimum deployment version | | ---------------------------------- | -------------------------- | | **macOS** | 13.3 | | **iOS** | 16.4 | Without mapping to the ref we can use the basic approach, because there is no reason pass the c++ objects as a ref to the swift code. [C++ Structures and Classes are Value Types by Default](https://www.swift.org/documentation/cxx-interop/#c-structures-and-classes-are-value-types-by-default) > [!info] > Swift maps C++ structures and classes to Swift `struct` types by default. Swift considers them to be [value types](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/classesandstructures#Structures-and-Enumerations-Are-Value-Types). This means that they’re always copied when they’re passed around in your Swift code. > > The special members of a C++ structure or class type are used by Swift when it needs to perform a copy of a value or dispose of a value when it goes out of scope. If the C++ type has a copy constructor, Swift will use it when a value of such type is copied in Swift. And if the C++ type has a destructor, Swift will call the destructor when a Swift value of such type is destroyed. > > C++ structures and classes with a deleted copy constructor are represented as non-copyable Swift types (`~Copyable`). If a C++ type has a valid copy constructor, it is still possible to make it non-copyable in Swift by annotating it with a `SWIFT_NONCOPYABLE` macro. > > Some C++ types are always passed around using a pointer or a reference in C++. As such it might not make sense to map them to value types in Swift. These types can be annotated in C++ to instruct the Swift compiler to map them to [reference types in Swift instead](https://www.swift.org/documentation/cxx-interop/#mapping-c-types-to-swift-reference-types). ___ ## Issues and Cons: 1. The simulator in Xcode 16.2 cannot compile the cpp interop with error: > <unknown>:0: error: compiling for iOS 12.0, but module 'Cxx' has a minimum deployment target of iOS 16.0: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator/Cxx.swiftmodule/arm64-apple-ios-simulator.swiftmodule The app can only be built on the Device or on the Xcode 15. 2. [Swift uses C++ types and calls C++ functions directly, without any kind of indirection or wrapping](https://www.swift.org/documentation/cxx-interop/#enabling-c-interoperability) but Swift maps C++ structures and classes to Swift `struct` types by default (This statement refers to **how Swift represents C++ structs and classes** internally.) This is why this **structs** cannot be used in the ObjC, because it works only with the NSObject types and primitives. The compile will make an attempt to import this types into the BridgingHeader.h and fails. C++ types may be used in the ObjC using the include directive only for the internal usage, but the flow: C++ -> Swift -> ObjC -> C++ is not acceptable. 3. There may be some compile errors that I failed to resolve: ![[Pasted image 20250103141849.png|400]] <img width="578" alt="image" src="https://github.com/user-attachments/assets/87101d7c-618c-410c-b942-7de8bbe0b9ec" /> 4. According to the documentation swift imports the cpp code as a module. For this purposes `modulemap` file should be created in the every framework. It is used to expose the cpp headers to the swift compiler. The `modulemap` compiles only the headers that it includes and do not compiles with the includes. It works for the cpp headers that have only a few logic /`includes` like the `gps_track_collection` or `elevation_info`: - compiles and visible for Swift: ```cpp module map { header "elevation_info.hpp" header "gps_track_collection.hpp" export * } ``` - This `modulemap` compiles but Swift still doesn't see the class `bookmark` at all (no error found): ```cpp module map { header "bookmark.hpp" export * } ``` - This `modulemap` does NOT compile at all: ```cpp module map { header "framework.hpp" // too complex to compile header "bookmark.hpp" header "track.hpp" header "elevation_info.hpp" header "gps_track_collection.hpp" export * } ``` with error: `__memory/allocator_traits.h:305:5: error: no matching function for call to '__construct_at'` ___ ### Conclusion At first glance, the idea to use the swift/cpp interop looks nice. But our cpp frameworks (map, kml, drape...) have **extremely high coupling** and cannot be used separately. This is why it seems impossible for the swift compiler to generate internal structures (that are exposed to the swift) for all of the entities that are used in the .hpp files (look at the `map/framework.hpp`). The second big issue is that the autogenerated swift structures cannot be used in the objective. It doesn't allow to use the cpp structs in a way: `cpp -> swift -> objc -> cpp` because objc doesn't support swift structs. Only the `cpp -> swift -> cpp` flow is accepted or our old approach with objc wrappers. But this feature still can be used for the small isolated frameworks that are not depends on the each other. For example `GpsTrackInfo` cpp struct can easily be used to pass around the Swift codebase (but not objc).

This repo is archived. You cannot comment on pull requests.

No reviewers