Has anyone ever considered a more "strict" flavor of C++ in which variables are / need to be initialized by default?

Question

While C++ is an extraordinary language it's also a language with many pitfalls, especially for inexperienced programmers. I'm talking about things like uninitialized variables of primitive types in a class, e.g.

class Data {
  std::string name;
  unsigned int version;
};

// ...

Data data;
if (data.version) { ... } // use of uninitialized member

I know this example is oversimplified but in practice even experienced developers sometimes forget to initialize their member variables in constructors. While leaving primitives uninitialized by default is probably a relic from C, it provides us the choice between performance (leave some data uninitialized) and correctness (initialize all data).

OK, but what if the logic was inverted? I mean what if all primitives were either initialized with zeros? Or would require explicit initialization whose lack would generate a compile error. Of course for full flexibility one would have a special syntax/type to leave a variable/member uninitialized, e.g.

unsigned int x = std::uninitialized_value;

or

Data::Data() : name(), version(std::uninitialized_value) {}

I understand this could cause problems with existing C++ code which allows uninitialized data but the new code could be wrapped in a special block (extern "C" comes to me mind as an example) to let the compiler know a particular piece of code shall be strictly checked for uninitialized data.

Putting compatibility issues aside, such an approach would result in less bugs in our code, which is what we are all interested in.

1. Have you ever heard about any proposal like this?
2. Does such a proposal make sense at all?
3. Do you see any downsides of this approach?

Note 1: I used the term "strict" as this idea is related to the "strict mode" from JavaScript language which as mentioned on Mozilla Developer Network site

eliminates some JavaScript silent errors by changing them to throw errors

Note 2: Please don't pay attention to the proposed syntax used in the proposal, it's there just to make a point.

Note 3: I'm aware of the fact that tools like cppcheck can easily find uninitialized member variables but my idea is about compile-time support for this kind of checks.

Answer 1

Use -Werror=uninitialized, it does exactly what you want.

You can then “unitialize” a variable with unsigned int x = x;

Answer 2

Have you ever heard about any proposal like this?
Does such a proposal make sense at all?
Do you see any downsides of this approach?

I haven't heard of any such proposal. To answer the next two, I'll first broadly claim that neither makes sense. To more specifically answer, we need to break the proposal down into two separate proposals:

1. No uninitialized variables of any kind are allowed.
2. "Uninitialized" variables are secretly initialized to some well-defined value (e.g. as in Java, which uses false, 0, or null).

---

Case 1 has a simple counterexample: performance. Examples abound; here's a (simplified) pattern I use in my code:

Foo x;
if (/*something*/) {
    x = Foo(...);
} else {
    x = Foo(...);
}
//[do something with x]

x is "uninitialized" here. The default constructor does get called (if Foo is an object), but this might just do nothing. If it's a big structure, then all I really pay for is the cost of the assignment operator--not the cost of some nontrivial constructor plus the cost of the assignment operator. If it's a typedef for an int or something, I need to load it into cache before xor eax,eaxing or whatever to clear it. If there's more code in the if-blocks, that's potentially a valuable cache miss if the compiler can't elide it.

---

Case 2 is trickier.

It turns out that modern operating systems actually do change the value of memory when it is allocated to processes (it's a security thing). So, there is a rudimentary form of this happening anyway.

You mention in particular that such an approach would result in [fewer] bugs in our code. I fundamentally disagree. Why would magically initializing things to some well-defined value make our code more robust? In fact, this semi-automatic initialization causes an enormous quantity of errors.

Storytime!

^{_{Exactly how this works depends on how the program is compiled (so debug vs. release and compiler). When I was first learning C++, I wrote a software rasterizer and concluded it worked--since it worked perfectly in debug mode. But, the instant I switched to release mode, I got a completely different result. Had the OS not initialized everything to zero so consistently in debug mode, I might have realized this sooner. This is an example of a bug caused by what you suggest.}}

^{_{By some miracle I managed to re-find this depressing question, which demonstrates similar confusions. This is a widespread problem.}}

Nowadays, some debugging environments put debug values into memory. E.g. MSVC puts 0xDEADBEEF and 0xFEEEFEEE. Lots more here. This, in combination with some OS sorcery, allows them to find use of uninitialized values. Running your code in a VM (e.g. Valgrind) gives you the same effect for free.

---

The larger point here is that, in my opinion, automatically initializing something to a well-defined value when you forget to initialize it is just as bad (if not worse) than getting some bogus value. The problem is the programmer is expecting something when he has no justification to--not that the value he's expecting is well-defined.