(Objective-C)++ interoperability is something we absolutely want to support at some point. It's a large feature with some significant dependencies (e.g. modules will need to be built as (Objective-)C++ rather than (Objective-C)), so while we have a rough outline of how we would tackle things, it's not a solid plan. The outline, courtesy of @John_McCall:
-
Switch Swift's Clang importer over to "Objective-C++" or "C++" mode (probably based on C++14 or even C++17), and start dealing with the fallout---we'll likely have to cope with C++ namespaces and using declarations, for example.
-
Making C++ language features with obvious analogues just work in Swift: non-trivially-copyable C++ classes as value types, member functions as methods, non-const references as inout parameters, extensions on C++ types, etc. Much of this is straightforward, but will be a lot of work.
-
Figuring out what to do with C++ language features without obvious analogues: non-copyable C++ classes, member pointers, reference members (C++ assignment semantics do not match our value semantics), etc.
-
Figuring out what to do with uses of templates from Swift. This is difficult because the generics models are so different, and a "complete" solution likely involves intertwining Clang and Swift if we're going to, e.g., instantiate a C++ template with a Swift type as a template argument.
-
C++ pattern recognition / annotation to become a more native-feeling API in Swift: importing types as reference types,
std::shared_ptr,std::pairandstd::tuple, etc. Lots of little pieces to design, implement, and test.
It's not clear how far one has to get to make a usable C++ interoperability story.
Doug