One thing I don't see in this list (though maybe I'm missing it) is the ability to expose a Swift function as a function compatible with the C ABI. Something like extern "C" in C++ or no_mangle in Rust.
You can pass @convention(c) blocks around as C function pointers, but you can't currently call directly into a Swift library from C code. That makes it difficult to do things like expose platform-specific functionality to a shared C library using Swift.
Right now you have to implement the C function inside an Objective-C file, and then have your Objective-C code call your Swift code, or you have to change all your interfaces to allow injection of function pointers for all external dependencies.
It's the kind of thing that makes staying with Objective-C attractive for that type of stuff, but Swift in general has been a solid improvement, and I'd like to not have to give that up.
Seems to be being worked on, an attribute @_cdecl has been merged into master [0] and seems to compile in the current beta of 3.0 [1] although I haven't tested it.
You're welcome. I have a custom mouse cursor a11y app that has to use some nasty old C callback API, which is exactly the PITA you describe, so I've been keeping an eye out.
Yes, I was hoping that 3.0 would allow C++ and Swift to call each other. Have spent a few thousand hours writing a reactive ontology in C++ that currently calls to and from ObjC.
I was asking about C++ support in the WWDC 2015 labs, and the answer was using an ObjC wrapper workaround. As a result, I put off a major port for "next year".
" ... However, C++ itself is a very complex language, and providing good interoperability with C++ is a significant undertaking that is out of scope for Swift 3.0. "
You can pass @convention(c) blocks around as C function pointers, but you can't currently call directly into a Swift library from C code. That makes it difficult to do things like expose platform-specific functionality to a shared C library using Swift.
Right now you have to implement the C function inside an Objective-C file, and then have your Objective-C code call your Swift code, or you have to change all your interfaces to allow injection of function pointers for all external dependencies.
It's the kind of thing that makes staying with Objective-C attractive for that type of stuff, but Swift in general has been a solid improvement, and I'd like to not have to give that up.