One could presumably compile arbitrary C++ to rust or D without changing semantics, then slowly go through the result making it look more native to the new language.
That would either be a wholesale conversion or emitting a translation shim style thing at the boundary between legacy c++ and the new language.
I'm not sure Carbon is necessary to achieve such a conversion.
I would be stunned if you could compile arbitrary c++ to rust or d, unless by "compile" you mean "painfully hand-translate and spend months fixing subtle errors". you are underestimating the sheer complexity of the language.
Agreed, but it would be much worse than you suggest. Many meaty C++ projects have an underlying architecture that could not even be expressed in (safe) Rust. The idea of transpiling a major C++ project and getting it running in Rust with only some minimal idiom fiddling seems utterly fantastical.
Implementation would be by modifying clang. Traverse the clang ast emitting the new language instead of llvm IR.
You wouldn't get idiomatic code out but with some effort you'd get rust/d/c/other which clang compiles to the same IR as the original.
How much refactoring is warranted afterwards would depend on how much effort you put in to recreating templates / header files / modules etc on the fly.
I'm not sure I'd choose to do this myself if I was in Google's position but it would be tempting.
you would end up with llvm-ir-like code that was only technically rust/d insofar as the compilers could handle it. it would not be human-readable or maintainable at all; indeed, it would be harder to convert that to idiomatic rust/d than hand-translating the c++ code. and really, all you would gain would be getting rid of the c++ compiler and ending up with worse code.
the point of carbon is that you can incrementally migrate your c++ program to it in place, and the migrated code will end up easier to maintain than the original c++.
This was essentially how DMD (the reference D compiler) was translated to D. However this was mostly a restricted subset of C++ common to both of them, e.g. no diamond inheritance, no operator overloading whackiness.
Nim would be the best choice for this at the moment, imho
importcpp what you need. exportcpp for the other way around