My understanding was that there is no need to involve Objective-C if you’re directly interfacing with C. That interop is direct/seamless, and works on Linux etc. even without Objective-C or Darwin [0].
But the C++ story is what you’ve described above.
[0] https://developer.apple.com/documentation/swift/imported_c_a...
and
https://developer.apple.com/documentation/swift/imported_c_a...
Re:Swift System Is Now Open Source
by wool_gather on Saturday September 26, 2020 @12:40PM
(#24600106)
I wouldn't say "seamless". Interacting with C directly from Swift is possible, and fine from a binary perspective, but quite clunky at the source level. (Which obviously is a motivation for the library that is being announced here.)
There are still assorted gaps in C imports -- a key example is forward-declared structs, that _all_ arrive in Swift as a _single shared_ `OpaquePointer` type: https://forums.swift.org/t/opaque-pointers-in-swift/6875
I was thinking of Objective-C++ which can freely call into C++.
Swift seems to be one step removed from that. I guess you would have to write an Objective-C to Objective-C++ bridge to then use from Swift, ugh.
Re:Swift System Is Now Open Source
by andrekandre on Friday September 25, 2020 @06:48PM
(#24594873)
obj-c is a direct superset of c, so that interop already requires plain c capabilities right out of the box
and afair obj-c interrop is only available/supported on apple platforms
C can be exposed as Objective C, but C++ has to go through C (potential objective C++) first.
This is really no different than most other languages.
What it does do is provide good auto binding tools however to expose classes and objects bidirectionally to objective C.