It seems that the goal is a new language with full interop with C++, kind of like Zig's interop with C. - I wonder how much baggage had to be maintained for in

It seems that the goal is a new language with full interop with C++, kind of like Zig's interop with C. - I wonder how much baggage had to be maintained for interop. If some of it could be isolated, how did they do it? - Does this fall into any of the traps that D initially did where it allowed C interop but was, by default, more limited in what C environments it could run in or is this as flexible as C++ for environments? As for the language itself, I've not had a chance to dig into it too much but I am sad to see that it uses explicit local inference by replacing the type name with `auto` rather than eliding the type completely [0]. While it has its pains at times, this is something I've come to enjoy in Rust. I also didn't see mention of tooling. Having out-of-the-box build, test, and code formatting would be a big help for establishing community standards / practices, even if the build/test tool might get limited when having to do C++ interop. At least for pure-Carbon libraries it would be a big help! > Once we can migrate code into Carbon, we will have a simplified language with room in the design space to add any necessary annotations or features, and infrastructure like generics to support safer design patterns. Longer term, we will build on this to introduce a safe Carbon subset. This will be a large and complex undertaking, and won't be in the 0.1 design. Meanwhile, we are closely watching and learning from efforts to add memory safe semantics onto C++ such as Rust-inspired lifetime annotations. I'm a bit skeptical if they push off lifetime annotations too far. [0] https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/type_inference.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...