It's been a very long time since I wrote any C++, but I find it unclear what it even means to have std::string adopt String's storage. IIRC, C++ strings make deep copies when they're passed around anyway (no reference counting ofc), and the C++ standard forbids copy-on-write, which is why people prefer to move them. Also they're mutable.
But you can't, in general, move a String's storage in to a std::string unless Swift no longer needs it (either via an explicit move or optimisation) and it turns out to be uniquely-referenced; although String may be able to adopt std::string's storage using our support for shared strings.
I could see something like string_view working, though.
I think some good terminology (that we can bike shed) is: Forward Interop for Swift consuming C++ APIs, Reverse/Backwards Interop for C++ consuming Swift APIs, and Bidirectional Interop when talking about both. (Because, when you're moving to Swift, you're moving forward )
IMO that would be harder to remember and no easier to say/write than simply "importing C++ [into Swift]" and "importing Swift [into C++]." Where the bracketed parts are optional in this context.
But that doesn't cover everything because you have two kinds of bridging for each kind of import. Calling a C++ function auto f(A) -> B from Swift involves bridging in both directions. I suggest
^ Same. This is great and I love what this could mean. Being able to directly interface with the swift standard library is a must-have and this achieves that so perfectly. Yes, I would love to be in the workgroup.
C++ interop has been implemented by extending the existing ClangImporter so far, hasn't it?
However, the current ClangImporter has potentially bugs because it is designed as a singleton.
I hope there would be some plans to split it into several classes to reduce such bugs, since there is an abstract class named ClangModuleLoader.
)