Carbon pointer safety rules when passing objects across the C++ interop boundary

Short answer

As of October 2026, Carbon has no stabilized, compiler-enforced safety rules governing pointers handed to C++. Carbon is an experimental language whose memory-safety design is still a stated goal rather than an implemented feature, and its C++ interop is deliberately built on the assumption that C++ code is unsafe. Practically, this means that when an object crosses the boundary, you should treat the handoff as an unsafe operation whose correctness rests on convention and programmer discipline, not on the compiler.

What is confirmed versus what is design intent

It is important to separate three things that are easy to conflate:

• Confirmed: Carbon's interop strategy targets source- and ABI-level compatibility with C++ (Clang/LLVM-based), so a Carbon function can call a C++ function taking pointers or references with little or no glue code. The boundary itself is thin.
• Confirmed: Carbon's memory-safety model (borrow checking, lifetime enforcement, safe pointer types) is documented as a future direction, not something the current explorer/toolchain enforces. There is no shipped borrow checker to suspend or preserve at the boundary today.
• Design intent, not shipped behavior: The long-term plan is that safe Carbon code will not be able to silently leak unsafe pointers, and that interop with unsafe C++ will require explicit opt-in. The exact mechanism (annotations, unsafe blocks, type-level distinctions) is not finalized and should not be relied on.

Answers to your specific questions

Are lifetime or ownership rules for pointers handed to C++ specified and enforced?

No enforcement exists today. Because the safety model itself is not yet implemented, there is nothing for the compiler to enforce when a pointer escapes into C++. If the C++ side stores the pointer beyond the call and the Carbon side later destroys the object, you get the same use-after-free you would in pure C++. The correct mental model is: the safety model is not 'suspended at the boundary' — it does not yet exist on either side of it.

Is there a documented type-level distinction for unsafe/interop pointers?

Not in a form you can build against. The design documents discuss distinguishing safe and unsafe operations, but there is no stable, documented annotation or pointer-type taxonomy for interop that the current toolchain checks. Anything you read describing specific attribute spellings or conversion methods should be treated as proposal-stage material that may change or never ship.

Are guarantees tied to a C++ standard or ABI version?

Interop is built on Clang/LLVM, so it inherits that toolchain's C++ ABI behavior on your platform. There are no additional Carbon-side guarantees layered on top, so the practical constraints are the usual C++ ones: matching object layout, matching ownership conventions, and a shared understanding of who frees what. If you mix toolchains or ABIs, you have the same problems as mixed-compiler C++ — Carbon neither adds to nor subtracts from that risk today.

Practical guidance for your evaluation

1. Adopt a convention that pointers passed to C++ are borrowed for the duration of the call only; document any C++ API that retains them as a known hazard.
2. Keep ownership on one side of the boundary per object; avoid designs where both sides can free the same allocation.
3. Validate with the tools you already trust: ASan/valgrind on the combined binary will catch cross-boundary lifetime bugs regardless of language.
4. Track the Carbon project's design documents rather than toolchain behavior; the safety story is where the churn is.

One caveat worth flagging: because the language evolves quickly, verify anything load-bearing against the current design docs and explorer before committing migration plans to it.