5 ms·

Swift has almost seamless interoperability with existing C and C++ libraries and has much stronger safety guarantees than either of those languages. It's not o

by wffurr 6y ago

Swift has almost seamless interoperability with existing C and C++ libraries and has much stronger safety guarantees than either of those languages. It's not on the same level as Rust, but ARC eliminates entire classes of memory safety issues. The Swift runtime is large-ish, but not outrageously so, and is generally statically compiled-in to the binaries, so there's no dependencies on dynamic libraries. It is, as you say, quite complex, but still an interesting choice IMO.

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.
mhh__ 6y ago
Swift can interface with C++? I've just done some googling but I cannot find any documentation at all relating to C++ interop. I make no assumption that I'm right but all I can see is interop via a C API Seamless in my mind is what D has where name mangling, templates, and classes all work on Windows, Linux (possibly MacOS - I don't have one). Does swift have any of that?
- jhatemyjob 6y ago
  On most platforms, if you can interface with C, you can also interface with C++. Usually you have to find the mangled symbol in the C++ binary using a tool like nm, and treat it like a C function with whatever ffi you're using. If you are targeting multiple platforms this can get tricky because the mangled C++ symbol will (probably) be different for each platform, which can be solved with a good build system
  - mhh__ 6y ago
    Eek. I've done it but not exactly seamless as implied above! (feels Like using a landmine as a baking scale)
    - jhatemyjob 6y ago
      What issues did you run into?
      - mhh__ 6y ago
        I've only ever done it out of curious laziness but it's one of those things where it's theoretically clean enough to do right but if you do it wrong you might be fixing it all day. If something changes downstream or you make a mistake at 9AM you can end up with subtle non-failing garbage everywhere. The only way I would do it and trust it, would be if the binding is generated and tested (separately) automatically, but at that stage why not just write one with a proper ABI.
  - moonchild 6y ago
plorkyeran 6y ago
Swift has great C interop for a language that is not a C superset, but C++ interop is at best a thing you can theoretically do. In practice c++ interop is usually done via a wrapper.

by wffurr 6y ago

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.

mhh__ 6y ago

Swift can interface with C++? I've just done some googling but I cannot find any documentation at all relating to C++ interop. I make no assumption that I'm right but all I can see is interop via a C API Seamless in my mind is what D has where name mangling, templates, and classes all work on Windows, Linux (possibly MacOS - I don't have one). Does swift have any of that?

jhatemyjob 6y ago
On most platforms, if you can interface with C, you can also interface with C++. Usually you have to find the mangled symbol in the C++ binary using a tool like nm, and treat it like a C function with whatever ffi you're using. If you are targeting multiple platforms this can get tricky because the mangled C++ symbol will (probably) be different for each platform, which can be solved with a good build system
- mhh__ 6y ago
  Eek. I've done it but not exactly seamless as implied above! (feels Like using a landmine as a baking scale)
  - jhatemyjob 6y ago
    What issues did you run into?
    - mhh__ 6y ago
      I've only ever done it out of curious laziness but it's one of those things where it's theoretically clean enough to do right but if you do it wrong you might be fixing it all day. If something changes downstream or you make a mistake at 9AM you can end up with subtle non-failing garbage everywhere. The only way I would do it and trust it, would be if the binding is generated and tested (separately) automatically, but at that stage why not just write one with a proper ABI.
- moonchild 6y ago

plorkyeran 6y ago

Swift has great C interop for a language that is not a C superset, but C++ interop is at best a thing you can theoretically do. In practice c++ interop is usually done via a wrapper.