Ah, the error was the other way around.

The idea that you form a value by creating an uninitialized one and then filling in its fields is dumb. (I suspect the field value wasn't even 0 as such but rather undefined, and the implementation happened to make it 0?). Better languages have you initialize the value directly and you can't access it until it's fully initialized. C/C++ are just really bad at expressing nontrivial values, even value literals.

(Discarding a value ought to be an error too, though that's more cumbersome to work with)

You can rightfully blame having state setting be part of your language. It is easier to program without state than with it, just like it's easier to juggle 2 balls than 3. Without state (or with the absolutely minimum of it) you can not make mistakes with it. Also, if your state-setting operator is super similar to your equality-checking operator, you can fall into this trap (like the devs in question did).

Programming without state is something that has helped me personally make my code much better. I produce less bugs by far since I stopped relying on state for so many things. A lot of micro-optimisations are not doable for me. In exchange I guess I get to run things in parallell very easily. But mostly, I get fewer bugs, which makes my life and the lives of my customers better.

Writing stateful code by default in hopes that it will be faster is a premature optimization IMNSHO.

A lot of times it isn't actually any faster, and it's certainly more error prone.

Picking up Clojure and learning to be extremely judicious about the use of persistent state reduced my bug output rate dramatically.

Amen to that! If Rich Hickey is reading this - it is to you I owe my thanks for the many hours I have not spent on fixing state bugs. Clojure was my first functional love story.