Interoperability failure during bidirectional C++ migration

Carbon-C++ Interop Boundary

Carbon is designed to allow incremental migration from C++ through bidirectional interoperability. This requires the Carbon compiler to maintain a consistent representation of types and memory layouts when interfacing with existing C++ codebases.

Given the experimental nature of the language, there is uncertainty regarding how the Carbon type system handles complex C++ template instantiations that rely on non-standard compiler extensions or specific ABI behaviors. If the Carbon compiler cannot map a C++ type precisely to its internal representation, the interoperability boundary may fail.

• What mechanism does Carbon use to resolve type mismatches when a C++ template exceeds the current specification's mapping capabilities?
• How is memory safety enforced when a Carbon pointer interacts with a C++ object that does not follow Carbon's safety invariants?