> As long as that is considered acceptable, your argument holds no water.

It is true that it costs more to hire more skilled developers, and for that reason we suffer. (e.g. Electron).

But even if that happens all the time, it does not mean that my point is invalid. If we want to reduce the energy waste, it starts from software as well.

> Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not.

For end-users yes, but not for any cloud computing, servers, et. all where the real computing happens. You can make significant saving in terms of required processors, memory and electricity simply by writing more efficient software. Just one method more to make world greener place.

The point is to focus on making correct code instead of relying into fallback mechanisms.

E.g. compare to increased popularity of Rust and what it means in this context.

> [...] it is the only way to call the no-arguments constructor for a variable on the stack

The syntax:

  T var{};

> it is the only way to call the no-arguments constructor for a variable on the stack.

Is that really true? Ouch. In many languages that wouldn't feel crazy, but in a language where there's a whole book about initialization https://leanpub.com/cppinitbook that feels kinda silly.

Having some means (as these C++ proposals all do) to explicitly say "I understand that you can't see why this is correct but it assure you it is" would be fine, and needn't be introduced to beginners at all. The problem as usual in C++ is that All The Defaults Are Wrong and because they're defaults we need to warn beginners about them.

You won't write Rust's MaybeUninit<T>::assume_init() in your first program by mistake, whereas the equivalent mistake in C++ happens easily because it's the default.

The question essentially is what the statement `T x;` should mean. Today, if T is class, it means "allocate space for a value of type T and construct it using T::T()". However, if T is a built-in type, it means "allocate space for a value of type T with no defined value", which has proven to be highly problematic in practice.

The situation could be improved in two simple ways. One, you could unify the two meanings, and say that `T x;` allocates space and calls T::T() to initialize the value. The no-args constructor for built-in types already exists and initializes them to 0.

Or, you could also say `T x;` is illegal syntax, one must write `T x = val;` always (or at least when T is a built-in type).

In either case, an escape hatch is needed for allocating uninitialized space on the stack, since there are valid performance reasons for wanting that, in rare cases. But that should be new syntax, it really really shouldn't be the default. So you can still do something like `T x = std::uninitialized();` or whatever the syntax would be to get the current behavior in performance-critical cases, where the tradeoff makes sense.

Personally, especially given C++'s use of templates that don't distinguish between built-in types and classes, I believe the first option makes the most sense, and in fact removes am ugly inconsistency from the language.

That's C++, which is not C. Granted, the C++ behavior is weird and annoying. (the C behavior, while better for truly-infinite loops, is still "broken" for potentially-not-but-still-possibly-infinite loops, though such should be less common)

N1570, 6.8.5, point 6 under "Semantics":

    An iteration statement whose controlling expression is not a constant expression,156) that
    performs no input/output operations, does not access volatile objects, and performs no
    synchronization or atomic operations in its body, controlling expression, or (in the case of
    a for statement) its expression-3, may be assumed by the implementation to terminate.

Note that the rules in C++ on this are different, and do allow even a constant-end-condition empty loop to be assumed to terminate.