C++ needs a proper 'uninitialozed' value state

*Uninitialized

Allowing values to stay uninitialized is dangerous. I think most people would agree in the general case.

However for a number of use-cases you'd want to avoid tying value lifetime to the raii paradigm. Sometimes you want to call a different constructor depending on your control flow. More rarely you want to destroy an object earlier and possibly reconstruct it while using the same memory. C++ of course allows you to do this, but then you're basically using a C logic with worse syntax and more UB edge cases.

Then there's the idea of destructive move constructors/assignments. It was an idea that spawned a lot of discussions 15 years ago, and supposedly it wasn't implemented in C++11 because of a lack of time. Of course without a proper 'destroyed' state of the value it becomes tricky to integrate this into the language since destructors are called automatically.

One frustrating case I've encountered the most often is the member initialization order. Unless you explicitly construct objects in the initializer list, they are default-constructed, even if you reassign them immediately after. Because of this you can't control the initialization order, and this is troublesome when the members depend on each order. For a language that prides itself on its performance and the control of memory, this is a real blunder for me.

Of course you can rely on the compuler optimizing out default constructions when they are reassigned after, but not really.

There's also the serious issue of memory safety. The new spec tries to alleviate issues by forcing some values to be 0-initialized and declaring use of uninitialized values as errors, but this is a bad approach imho. At least we should be able to explicitly avoid this by marking values as uninitialized, until we call constructors later.

This isn't a hard thing to do I think. How much trouble would I get into if I were to make a proposal for an `int a = ?` syntax?

https://redd.it/1omeoh1
@r_cpp