As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features?
I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can continue to add features - which are usually decent ideas given the context, kudos to the authors for the effort - but the language will decline faster than it can be fixed. Furthermore, the language seems to be continually becoming harder to implement, support, and write due to the constant feature addition and increase in semantic interconnectivity. To me it's almost mostly a theoretical exercise to add features at this point: practically we end up with oddly specced features which mostly work but are fundamentally crippled because they need to dodge an encyclopedia of edge cases. The committee are really letting the vision of a good C++ down by refusing to break backwards compatibility to fix core problems. I'm talking fundamental types, implicit conversions, initialisation, preprocessor, undefined / ill-formed NDR behaviour. The C++ I'm passionate about is dead without some big changes I don't think the community can/will handle.
bluGill · 26s ago
That doesn't matter -
it cost a billion dollars to write the current project I work on. There is no way I can ask for that much to rewrite it all in whatever. Thus we are stuck on c++ which was the best choice 15 years ago. Anything that makes new code easier to write is great help.
sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while but I'm not sure how it fits (d supports c++ abi)
gblargg · 25m ago
> It’s well-defined, yet incorrect behaviour that compilers are recommended to diagnose. Is recommended enough?! Well, with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game.
Is this to cover cases that would be hard/costly to detect? For example you pass the address of an uninitialized variable to a function in another source file that might read or just write to it, but the compiler can't know.
bluGill · 5m ago
Right. The compiler needs to diagnose where it can but the are many cases it cannot be sure.
I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can continue to add features - which are usually decent ideas given the context, kudos to the authors for the effort - but the language will decline faster than it can be fixed. Furthermore, the language seems to be continually becoming harder to implement, support, and write due to the constant feature addition and increase in semantic interconnectivity. To me it's almost mostly a theoretical exercise to add features at this point: practically we end up with oddly specced features which mostly work but are fundamentally crippled because they need to dodge an encyclopedia of edge cases. The committee are really letting the vision of a good C++ down by refusing to break backwards compatibility to fix core problems. I'm talking fundamental types, implicit conversions, initialisation, preprocessor, undefined / ill-formed NDR behaviour. The C++ I'm passionate about is dead without some big changes I don't think the community can/will handle.
sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while but I'm not sure how it fits (d supports c++ abi)
Is this to cover cases that would be hard/costly to detect? For example you pass the address of an uninitialized variable to a function in another source file that might read or just write to it, but the compiler can't know.