3 ms·

Minor nitpick but it does not have seamless interfacing with anything other than Objective C. C can be exposed as Objective C, but C++ has to go through C (pot

by dagmx 6y ago

Minor nitpick but it does not have seamless interfacing with anything other than Objective C. 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.

deleted 6y ago
[deleted]
ladon86 6y ago
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_and_objective-c_apis/using_imported_c_functions_in_swift https://developer.apple.com/documentation/swift/imported_c_a... and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift https://developer.apple.com/documentation/swift/imported_c_a...
- wool_gather 6y ago
  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 https://forums.swift.org/t/opaque-pointers-in-swift/6875
andrekandre 6y ago
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
wffurr 6y ago
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.

by dagmx 6y ago

deleted 6y ago

[deleted]

ladon86 6y ago

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_and_objective-c_apis/using_imported_c_functions_in_swift https://developer.apple.com/documentation/swift/imported_c_a... and https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_structs_and_unions_in_swift https://developer.apple.com/documentation/swift/imported_c_a...

wool_gather 6y ago
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 https://forums.swift.org/t/opaque-pointers-in-swift/6875

andrekandre 6y ago

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

wffurr 6y ago

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.