> When that is not required for the project at hand, we happily reach out to C#, D, Java, Go, Rust, Zig, Swift, Odin,.... instead.
Which is all well and good for us, the application developers. But if C++ wants to exist in the future as a thriving language (as opposed to moving in to the nursing home with Cobol and Fortran), then it needs to come up with some solution to remove cruft.
Part of their ‘problem’ is that they have lots and lots of users with long-living code bases. That means that, if they move fast and break things, their users won’t move to newer versions of the language.
Another part is that they want to be able to generate the fastest code possible. That leads to such things as having all kinds of constructors (‘normal’ ones, copy constructors, move constructors), and giving developers the ability to tweak them for maximum performance.
In addition, a lot of this was invented after the language was in use for decades. I think that makes the constructor story more complicated than needed.
Which is all well and good for us, the application developers. But if C++ wants to exist in the future as a thriving language (as opposed to moving in to the nursing home with Cobol and Fortran), then it needs to come up with some solution to remove cruft.