Full Feature Parity with C++

[sirinath]

If this is a successor language there would be parity with each other and 2 way code transformation from any valid C++ to a subset of Carbon and sub set of Carbon to C++. If features like multiple inheritance is dropped this will become awkward for humans and difficult to reason. When looking at C++ or Carbon a skilled programmer should also be able to deduce the code in the other form.

[sanxiyn]

One obvious way forward is to instrument a C++ compiler (probably Clang) to log whenever C++ features outside of Carbon C++ interoperability subset are used (e.g. multiple inheritance, exceptions, SFINAE), and run it on source codes in the wild, for example, by doing Debian archive rebuild. This will produce data relevant to the question whether Carbon's current C++ interoperability subset is large enough in practice.

[sirinath]

I think all C++ should have a direct Carbon equivalent but not the other way around unless you use a sub set,

[sanxiyn]

Why? What advantage does full feature parity provide if those features aren't used in practice? As an extreme example, export template was a C++ feature but it was removed in C++11 because it was rarely used. If there is a feature in C++17 (current Carbon interoperability target) which is similarly rarely used, it would make a lot of sense to omit it in Carbon.

[jwtowner]

One of the primary use cases of multiple inheritance in modern C++ programming is to implement things like mixin classes or static polymorphism via the Curiously Recurring Template Pattern. It appears work is being done to add support for mixins, so we still get many of the semantic benefits of multiple inheritance without the legacy baggage.

What matters is that we get semantic equivalence, within reason, between C++ and Carbon, not necessarily syntactic equivalence.

[lexi-nadia]

Hi! :) Please see https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/interoperability/philosophy_and_goals.md, which addresses this issue.