I’m not sure exactly what you’re asking, but it’s just basically writing a C header file as an API, but the implementation is in a source file that is in C++.

I see, so you're just writing the bridge code yourself. OK, I do the same in Objective-C++, so at least it gives me an object-based interface, as well. But saving this step and having a direct Swift <-> C++ would be helpful.

Yeah for me it's just about keeping Obj-C out of the project. It's enough to have two languages, I don't want to unnecessarily add a third.

Don't you already have 3 languages to think about? Swift, C and C++?

The C API is usually syntactically valid C++, so I don’t think of it that way. It’s just an API. Implementation is still in just two languages.

I mean, you also have to be careful to return pointers and not smart pointers and so on. It can be a bunch of work if you need to write a bunch of freestanding functions to wrap the c++ object methods.

Well, you won't return smart pointers if your header file is in fact a C API, since smart pointers are C++ only.

It's usually as simple as calling data() on a vector or std::string (as well as having a function to return the length or size of the data buffer). And if you wrap your header file in the normal C externs, it shouldn't compile if you do things that are not allowed in C, if I remember.

But you are right it can be a lot of work if you have a large surface area. I try to stick to tight, focused APIs, and data is normal C structs which work fine in C++ as well.