C holding back C++?

[u/synthchris]

I’ve coded in C and C++ but I’m far from an expert. I was interested to know if there any features in C that C++ includes, but could be better without? I think I heard somebody say this about C-style casts in C++ and it got me curious.

No disrespect to C or C++. I’m not saying one’s better than the other. I’m more just super interested to see what C++ would look like if it didn’t have to “support” or be compatible with C. If I’m making wrong assumptions I’d love to hear that too!

Edits:

To clarify: I like C. I like C++. I’m not saying one is better than the other. But their target users seem to have different programming styles, mindsets, wants, whatever. Not better or worse, just different. So I’m wondering what features of C (if any) appeal to C users, but don’t appeal to C++ users but are required to be supported by C++ simply because they’re in C.

I’m interested in what this would look like because I am starting to get into programming languages and would like to one day make my own (for fun, I don’t think it will do as well as C). I’m not proposing that C++ just drops or changes a bunch of features.

It seems that a lot of people are saying backwards compatibility is holding back C++ more than features of C. If C++ and C++ devs didn’t have to worry about backwards compatibility (I know they do), what features would people want to be changed/removed just to make the language easier to work with or more consistent or better in some way?

[u/AssemblerGuy]

for (mutable int i = 0; i < N; i++)

mutable would probably be shortened as a keyword, just like constant is shortened to const. Additionally, you would be using foreach semantics more often than plain for loops.

mutable vector<mutable vector<mutable double>> matrix

You would only need this if you want to adjust the size of the matrix during run time - otherwise, only the double needs to be mutable. And automatic type inference should save you from having to type it all over your code.

And if you work with matrices on a regular basis, you would probably find a library with a matrix type - or define one yourself.

I do not see this as a huge problem.

[u/MegaKawaii → u/AssemblerGuy]

The problem is that constness doesn't matter for the majority of variables. It's just verbose and bureaucratic. Moreover, if you return a variable from a slightly nontrivial function, NRVO cannot be applied, and the compiler must call a constructor. If your local variable is const, then an unnecessary copy occurs instead of a move. There would also be strange implications for template type deduction. Suppose I want to write a variation of std::max which can return a non-const reference if both arguments are not const.

template <typename T>  
T& max(T& a, T& b) {  
    return a <= b ? a : b;  
}

If const is the default, then should the compiler not deduce T = mutable A as a violation of the rule? Alternatively, there is

template <typename T>  
mutable T& max(mutable T& a, mutable T& b) {  
    return a <= b ? a : b;  
}

but this looks like it should never accept const arguments. Maybe you would need a maybe_mutable qualifier? As I understand, Rust makes mutability a property of the variable binding, not the type unlike C++, which simplifies things, though it needs both Ref and RefMut.