Comment by w10-1
10 hours ago
I believe Apple is investing in C/C++ interop so much because they realize they'll likely keep their existing low-level system+embedded code rather than port it to Swift. That's good for people who want to do the same. A swift API layer can reduce the need for C/C++ developers.
But in my experience, there are sharp cliffs whenever you get off the happy path shown in the demos. That's not a problem with code where you can design workarounds, but when you wrap highly complex (if not arcane) C API, you often can't change or omit portions of the API causing problems. So while usability may be better, apinotes might not be enough to complete the work.
If you're wrapping something, I would recommend cataloging and then verifying all the language features you need to make it work before getting too far in.
> so much because they realize they'll likely keep their existing low-level system+embedded code rather than port it to Swift
I disagree. I think it’s more that it reduces the burden to port to swift. Of course there’s some stuff you’ll never be able to port because of external factors, but reducing the burden to introduce a language is the first step in allowing more stuff to be shifted to that language transparently.
Yep. They also have a history of strong C/C++ interop with objective-c being based on C and objective-c++ (which allows compiling C++ and objective-c in one code file) also being a thing. I bet part of this is a good migration path for code (Apple and 3rd party) that uses that.
Sure they will keep C/C++, and various low-level code: Swift is nice for developers but slow for execution (compared tose).