> I very much don't want that

Why? What does it cost you?

Making something a valid program that shouldn't be. Thus, potentially creating/hiding bugs. I also explicitly invoke UB on all the code paths I do not want to be valid.

I've had the pleasure of spending many hours hunting down an uninitialized variable, as its value would change anytime I got close to it. BTW, if you really, really, want an uninitialized variable:

    int x = void;

will do it.

I don't think preventing the bug is what's being objected to. Rather that the proposed solution replaces one buggy program with another. If people are inadvertently forgetting to initialize things then you should simply halt compilation when you detect that.

To be clear I think D default initializing is better than C leaving uninitialized. I just don't think it's optimal since the issue isn't one of convenience but rather bug prevention.

You're the first who has told me he doesn't like default initialization!

I literally also did in this thread.

I can't possibly be the first - several other comments here are saying the same thing including the one I was trying to clarify with you.

I don't dislike it per se. I think it's an improvement over not having it but I also think that it's sub-optimal in many scenarios when compared to simply failing the build. Since it's a tradeoff to prevent bugs at the expense of language brevity I don't think it should be surprising that not everyone agrees about it.

My personal preference is the "void" that D has for uninitialized in addition to empty braces or something similarly terse for default initialization.

Slight tangent but somehow C++ ended up with the worst of all possible worlds. Some types uninitialized by default, other types default initialized, terse initialization syntax variants that look highly similar but do different things, and much of it context dependent.

D is consistent in that structs also default initialize:

    struct S { int a; float f; }
    S s;

For C, having an error when the initializer is omitted is better than nothing. However, that is not part of the C Standard, and you'll be relying on having a C compiler with that extension. Otherwise there is undefined behavior. To do it right means it needs to be standardized.

Sorry, but I wouldn't like that either. I often intentionally don't initialize members and don't want that to be an error. How would you initialize the following:

    struct S  {
         enum {
              NO_MODE,
              MODE_A,
              MODE_B,
              MODE_C,
         } mode;
         union {
             struct mode_a {
                 float x, y;
             } a;
             struct mode_c {
                 time_t start;
                 bool flag;
             } c;
         };
    };

    S s;
    s.mode = NO_MODE;

?