For this case, there is the [[indeterminate]] attribute.

#1 Require initialization (like many modern languages). Makes sense. But now your existing C++ doesn't even compile so that's a hard "No" from the committee.

#2 Status quo, evaluating uninitialized variables is Undefined Behaviour. We cannot diagnose this reliably, any attempt will be Best Effort and several vendors already supply this but when it doesn't catch you arbitrary nonsense happens.

#3 Zero init. Now not initializing has defined behaviour, all the diagnostic tools we saw in #2 are invalidated and must be removed, but did you actually mean zero? Awful bugs still occur and now our best tools to solve them are crippled. Ouch.

#4 Erroneous Behaviour. Unlike #3 we do not invalidate those diagnostic tools from #2 because we've said the tool was correct. However, we do avoid Undefined Behaviour, something bad might happen but at least it's something you can reason about and it is clearly stated that it's your fault.

Because it is an actual security vulnerability if you cross privilege boundaries (infoleaks/(K)ASLR bypass, etc.), and one people often miss at that.

Say you write:

    struct { long long a; char b; } foo; foo.a = 0; foo.b = 1; return foo;

GCC's `-ftrivial-auto-var-init=pattern` currently initializes all unknown-value stack variables with 0xFEFEFEFE(...). This is usually an invalid fp value, invalid offset and invalid virtual address, allowing crashes to happen. This is a good thing.

Regarding performance, there is an attribute to opt out (both for the standard C++26 feature and the GCC option that is a subset of it)

Like any language that lasts (including Python and Rust) you subset it over time: you end up with linters and sanitizers and static analyzers and LSP servers, you have a build. But setting up a build is a one-time cost and maintaining a build is a fact of life, even JavaScript is often/usually the output of a build.

And with the build done right? Maybe you dont want C++ if youre both moving fast and doing safety or security critical stuff (as in, browser, sshd, avionics critical) but you shouldnt be moving fast on avoinics software to begin with.

And for stuff outside of that "even one buffer overflow is too many" Venn?

C++ doesn't segfault more than either of those after its cleared clang-tidy and ASAN. Python linking shoddy native stuff crashes way more.

https://safecpp.org/draft.html

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)

I would personally like a safe (and fast) subset that doesn't require me to be vigilant but catches every thing I could do wrong to the same level as rust. Then, like rust, you could remove that flag for a few low-level parts that for some reason need to be "unsafe" (maybe because they call into the OS).

There was a good talk from the WebKit team about stuff they did to get more safety.

https://www.youtube.com/watch?v=RLw13wLM5Ko

Some of it was AST level checks. IIRC, they have a pre-commit check that there is no pointer math being used. They went over how to change code with pointer math into safe code with zero change in performance.

A similar one was Ref usage checking where they could effectively see a ref counted object was being passed to as a raw pointer to a function that might free the ref and then still used in the calling function. They could detect that with an AST based checker.

That said, I have no idea how they (the C++ committee) are going to fix all the issues. --no-undefined-behavior would be a start. Can they get rid of the perf bombs with std::move? Why do I have to remember that shit?

This is an interesting perspective to me, because my view as someone who's been using Rust since close to 1.0 and hasn't done much more than dabbled in C++ over the years is basically the opposite. My (admittedly limited) understanding is that this has never really been a goal of the committee, because if someone is willing to sacrifice backwards compatibility, they could presumably just switch to using one of those other languages at that point. Arguably the main selling point of C++ today is the fact that there's a massive set of existing codebases out there (both libraries that someone might want to use and applications that might still be worked on), and for the majority of them, being rewritten would be at best a huge effort and more realistically not something going to be seriously considered.

If the safety and ergonomics of C++ are a concern, I guess I'm not sure why someone would pick it over another language for a newly-started codebase. In terms of safety, Rust is an option that exists today without needing C++ to change. Ergonomics are a bit less clear-cut, but I'd argue that most of the significant divergences in ergonomics between languages are pretty subjective, and it's not obvious to me that there's a significant enough gap in between Rust's and C++'s respective choices that warrant a new language that's not compatible with C++ but is far enough from Rust for someone to refuse to use it on the basis ergonomics alone. It seems to me like "close enough to C++ to attract the people who don't want to use Rust but far enough from Rust to justify breaking C++'s backwards compatibility" is just too narrow a niche for it to be worth it for C++ to go after.

Most of the rest of my complaints could be addressed by jettisoning backward compatibility and switching to more sensible defaults. I realize this will never happen.

C++ still has some unique strengths, particularly around metaprogramming compared to other popular systems languages. It also is pretty good at allowing you to build safe and efficient abstractions around some ugly edge cases that are unavoidable in systems programming. Languages like Rust are a bit too restrictive to handle some of these cases gracefully.

The difference in API shapes in their respective standard libraries is because of culture not technology. Easy to see example: In C++ the two fundamental sort functions are named sort and stable_sort. In Rust those same two sorts are named sort_unstable and sort, a subtle but crucial safer choice. Or compare C++ vector::pop_back against Rust Vec::pop

They love to say C++ is for everyone but it is clearly not. Only wizards and nerds burdened by sunk cost fallacy is willingly writing these modern C++ code. I personally just use C++ as a "nicer" C.

Also things often just don’t compose well. For example if you have a nested class that you want to use in an unordered_set in its parent class then you just can’t do it because you can’t put the std::hash specialization anywhere legal. It’s just two parts of the language which are totally valid on their own but don’t work together. Stuff like this is such a common problem in c++ that it drives me nuts

IIUC this is what Profiles are. It’s an opt in source file method to ban certain misfeatures and require certain other safe features.

Backwards compatibility is what keeps C and C++ relevant, for better or worse.

All major languages value backwards compatibility to certain extent.

Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things around.

Perhaps a better language could even get some traction without major corporate sponsorship. I think (?) rust and zig are examples of that.

Memory safety semantics aside (needed and will be disruptive, even if done gradually) ---

You could get 80% of the way to ergonomic parity via a 1:1 re-syntaxing, just like Reason (new syntax for OCaml) and Elixer (new syntax for Erlang). C++ has good bones but bad defaults. Why shouldn't things be const by default? Why can't we do destructuring in more places? Why is it so annoying to define local functions? Why do we have approximately three zillion ways of initializing a variable?

You can address a lot of the pain points by making an alternative, clean-looking "modern" syntax that, because it's actually the same language as C++, would have perfect interoperability.

"no one goes there anymore it's too crowded"

It's widely used and you can do so effectively if you need it as know what you're doing.

As long as there are people willing to put in the work to convince the standards committee that the proposals they champion are worth adding to C++ (and as long as there is a committee to convince, I suppose), then new versions of C++ will continue to be released.

> there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11.

Sure, different developers will find different features compelling and so will be comfortable living with different standards. That one group is fine with existing features shouldn't automatically prevent another from continuing to improve the language if they can gain consensus, though.