Is C++ Doomed?

From a post in /r/cpp [1],

> As of C++20, the right way to write a trivial getter in C++ looks like `[[nodiscard]] constexpr auto GetFoo() const noexcept -> Foo { return foo_; }`

C++>11 is such a mess than most useful changes are invisible to most users due to bloat.

I think it's way past time to call it quits and abandon active development of the language. New features will come from other languages without 35 years of baggage.

[1] https://www.reddit.com/r/cpp/comments/swv6wh/when_not_to_use...

that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as good as returning nullptr, in this case. And what strength of an exception guarantee does one really need? A basic guarantee is not that bad to give and most things do not need to worry if they don't use unmanaged resources without RAII types(e.g pointers).

But the big thing is, a large amount of code does not have error states at all, they always work. Another chunk have preconditions, that are generally developer errors, that shouldn't be throwing either. That leaves the parts that interact externally. And here is where one learns, it's not a dichotomy of exceptions or error flags/results... it can be both. It's more to do with the shape of the code.

One example is, one is passing a string buffer to a parser, an exception is probably fine as the error cannot be dealt with within the parser. It didn't create the malformed document and cannot fix it. To use error types will greatly complicate the inner workings of the library as it has to deal with errors at a majority of calls internally. This leads to more bugs(assuming more code == more bugs) and complexity/branches. One already paid for the branch to check for the error in the document too, now they have to pay for branching up the stack. Exceptions strong part is that they cannot be implicitly ignored. One can do that with error types that force a read prior to destruction too though.

For short distance things, where one is handling the error state after the call, not throwing is fine.

While that is true, this in turn means that the result is complex. You have old and new ways to do things, and new things are complex with all the integrations into the different parts.

Unified initialization sounds great, always use brace initialisation and be done, you think ... but no it's complex.

Or move semantics and universal(?) references are introduced to solve efficiency problems and make things nicer. For simple stuff it works, but oh the mess becomes wild.

How well modules will work out is still to be seen. Suddenly you need the build system to be a compiler and can't parallel build everything anymore, but have to create a dependency graph to build in order, while the standard treats that as a implementation detail.

C++ has some great features, however it would need a big cleanup, a cleanup which would break all code, worse than Python 2 vs. Python 3, in a world where other environments and languages are viable alternatives. Thus C++ can't afford the big jump.

> Using C++ with exceptions disabled is the only foolproof way to run it in a large heterogenous application.

Is there a way for a ctor to report failure in newer C++ standards or are exceptions still the only way[1]?

[1] https://www.yosefk.com/c++fqa/exceptions.html#fqa-17.2

How is a factory function not idiomatic? It's not as if C++ is a single paradigm language that encourages a singular style or paradigm like OO.

RAII is a mess in certain circumstances (looking at you, Vulkan API) and sometimes straight up just doesn't work anyway.

If your initialisation is prone to failure, don't do it in a ctor.