[gituliar]

> Unfortunately, I am all too well aware of why these decisions were made, and it is exactly one reason: Compatibility with legacy code. C++ has no editions system, no way to deprecate core language features.

Actually, I'm curious if somebody is working on a flavor of the modern C++ that abandons backward compatibility ?

The Carbon project feels like a completely new language. What I'd expect instead is something that adopts best features and practices from modern C++, so that an average C++ project would require just minor changes to migrate, in spirit of Python 2 -> 3 migration.

[doodpants]

Have you looked at the CppFront[1] project by Herb Sutter? It's less of a completely new language like Carbon. It's meant to be C++ with a "nicer" syntax, while providing 100% linking compatibility, and with 100% source backward compatibility available when desired.

[1] https://github.com/hsutter/cppfront

[pjc50]

> I'm curious if somebody is working on a flavor of the modern C++ that abandons backward compatibility ?

This is just Rust. You can't really deprecate bare pointers in C++ without completely wrecking the language.

[HALtheWise]

This... seems false? In particular, the point of an "edition" system is that code written for the new edition can seamlessly import code written for the old edition, and so a hypothetical pointerless "new edition" would simply disallow bare pointers in new files, and things like smart pointers would continue to be _implemented_ in old edition code.

[steveklabnik]

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

[pjc50]

> would simply disallow bare pointers in new files

And all their header files. That's a real Year Zero moment: you've just cut yourself off from the standard library, as well as most of the code you might want to link to. I don't think there's any "simpler" about it.

[TillE]

You can get to a pretty clean modern C++ by convention and compiler warnings and static analysis.

Carbon is a completely new language, and that's the point. Part of the language design is making compilation a lot faster, for example, as well as features that C++ can't realistically implement, while retaining C++ interop. It's an exciting way forward if they manage to achieve their goals, and it would be a way to gradually migrate C++ projects.

[omoikane]

A new language will eventually acquire its own grungy legacy just like C++ did, unless that new language aggressively breaks backward compatibility.

I think the best practice is for people to stick to a subset of safe patterns in mature languages. For C++, that's probably the C++ Core Guidelines:

https://isocpp.github.io/CppCoreGuidelines/

[thecodedmessage]

C++ was grungy in the 90’s, and, well, Rust as it is now is better than C++ as it is now, the comparison that matters now. Rust in 30 years will be better than C++ in 30 years. And safety is a big deal feature, and Rust has it. If it doesn’t have future big deal features, future languages can have it.

I reject the notion that C++‘s “maturity” is a substantial advantage given its unsafety.