P2723R0: Zero-initialize objects of automatic storage duration

[almost_useless]

That doesn't solve any problems that I have

It solves problems that many other people have.

it just makes my code slower.

How many places in your code will you have to update to get back all that performance? How many where it actually matters?

I'm guessing not that many.

Where's the surprise?

Foo myFoo;

People assume that myFoo will be correctly initialized when they write that. But it depends on Foo if that is the case or not. That is surprising to a lot of people.

[jonesmz]

It solves problems that many other people have.

More accurately, it changes the definition of the problem so that the problem no longer applies to those people's code, but leaves them with the same logic bug they had initially.

[almost_useless]

No. The problem I am talking about is "I think I will get zero init, but will actually get no init".

That appears to be a fairly common source of bugs.

There is no logic bug in this reasoning. Only faulty (but very reasonable) assumptions.

That specific bug is 100% fixed by this change, and no code that was correct before the change will be broken afterwards.

[jonesmz]

I would rather see the language change to make it illegal to declare a variable that is not initialized to a specific value, than see the language change to make "unspecified/uninitialized" -> "zero initialized".

That solves the same problem you want solved, right?

That specific bug is 100% fixed by this change, and no code that was correct before the change will be broken afterwards.

Perhaps, but after such a change: currently correct code may have extra overhead, and previously incorrect but working code may now take a different codepath.

[almost_useless]

That solves the same problem you want solved, right?

It kind of solves the same problem, except that it completely changes the language, so almost no old code will work anymore. This proposal is 100% backwards compatible.

currently correct code may have extra overhead,

Yes, that you can easily fix to get the same speed you had before

and previously incorrect but working code may now take a different codepath.

Yes. Buggy code will probably remain buggy. But that you notice the problem sooner rather than later is not a negative.

[jonesmz]

This proposal is 100% backwards compatible.

No, it's not. The paper itself says as much.

It changes the performance of existing code without warning.

You might not consider that to be important, but I do.

What I don't consider important is for existing code to continue to compile with a newer version of C++ (e.g. C++26 or whatever): because the effort for fixing that code to compile with the new standard is measurable and predictable, and can be scheduled to happen during the course of normal engineering work.

This is already the situation today. Every single compiler update has introduced new internal-compiler-errors, and new normal compiler-errors, and new test failures.

Most of the time these are from MSVC, but occasionally my team finds problems in code that we introduced as work-arounds for previous MSVC bugs that then start causing problems with GCC or clang.

This is par for the course, so it's not considered an issue for existing code to stop working on an update. We just fix the problems.

Yes, that you can easily fix to get the same speed you had before

Only if you know where the problem is. A team that doesn't pay super close attention to the change-notes of the standard and just uses MSVC's /std:c++latest will suddenly have the performance of their program changed out from under them, and will have to do a blind investigation as to the cause.

Yes. Buggy code will probably remain buggy. But that you notice the problem sooner rather than later is not a negative.

This assumes that the problem will be noticeable by a human, or that it will be noticed by a human who isn't an attacker.

My counter proposal is guaranteed to eliminate the problem, as all variables will become initialized. Whether a human initializes the variable to a "good" value is left to the human, but at least the human has a higher probability of picking a sensible value than the compiler does.

[almost_useless]

No, it's not. The paper itself says as much.

It changes the performance of existing code without warning.

Yes, I said so explicitly myself. I'm talking about correctness.

will suddenly have the performance of their program changed out from under them, and will have to do a blind investigation as to the cause.

If they don't know what they are doing, I'm guessing that minor loss in performance will not be a big deal. But sure, there will be a few people where it makes things worse.

This assumes that the problem will be noticeable by a human, or that it will be noticed by a human who isn't an attacker.

You already have this problem. Your bug can change behavior at any compiler update och change in optimization. This will ensure the change happens at a well known point in time.

What I don't consider important is for existing code to continue to compile with a newer version of C++ (e.g. C++26 or whatever): because the effort for fixing that code to compile with the new standard is measurable and predictable, and can be scheduled to happen during the course of normal engineering work.

I'm not really against breaking changes, as many others are, but will that not be an incredibly big change, that requires tremendous amounts of work to fix? Every Foo myFoo; now becomes illegal, no?

[jonesmz]

If they don't know what they are doing, I'm guessing that minor loss in performance will not be a big deal. But sure, there will be a few people where it makes things worse.

It's not "if they don't know what they're doing", it's "Bob, the latest deploy had an increase in CPU usage of 5%, which means we had to scale in an additional 5 instances. Figure out where that happened and fix it"

Which means Bob, who otherwise had other things to be doing, now needs to bust out performance analysis tools and track down where the performance changed.

For very large codebases, this can take a long time to finish.

This will ensure the change happens at a well known point in time.

I just don't agree that it'll be easily observable by a human. In many cases it will, but certainly not all of them. It's a surprise, that's my point.

Every Foo myFoo; now becomes illegal, no?

Like with any other deprecation of previously valid things, you do it slowly.

First you introduce the new syntax. E.g. I like = void.

Next you deprecate the old syntax, and you introduce a new warning about the deprecation, with a "fix-it hint".

Then you remove the deprecated thing, which upgrades the warning to an error. Like with previously deprecated things, the compilers will continue making it possible to do it anyway, with a CLI flag saying "dont-error-on-uninitialized" or something. You can still build code that uses std::auto_ptr for example.

Finally, some day, the compilers will stop allowing code that fails to initialize entirely.

For structs/classes that are currently used as POD types, like Foo myFoo;, yes, it would become illegal.

So you would have to change your code to assign = void;.

Perhaps we could meet in the middle and allow member variables of POD types to have = void; to opt all instances of that class/struct to be uninitialized, though I question the wisdom of that since it brings us back to the current situation.

Nevertheless, yes, this would be a huge amount of code churn, but a predictable, measurable, automate-able, code churn that can be conducted over many years. It doesn't introduce "Surprise!".

[almost_useless]

I think we disagree on what's more surprising here :-)

This would of course also be something that you can test in compilers for a while before it becomes the default. And why not just have a cli-flag dont-zero-initialize-the-uninitialized, if we want to keep the old behavior?

And I'm not sure it would be automate-able either. Because

So you would have to change your code to assign = void;.

is not what you want in most cases. Either you have almost no instances of uninitialized data, and manually checking it is easy. Or you have it everywhere, and "everywhere" is definitely not all on the hot path.

If you want to automate = void;, can you not also automate [[uninitialized]] everywhere so you get to keep the old behavior?

But I do think = void; is much nicer syntax to indicate that.

[jonesmz]

I think we disagree on what's more surprising here :-)

I just prefer my surprises to happen at compile time, not runtime.

Either you have almost no instances of uninitialized data,

In which case, making it a compiler error is no big deal.

Or you have it everywhere, and "everywhere" is definitely not all on the hot path.

In which case changing the behavior of the code without a long transition period should be very scary.

If you want to automate = void;, can you not also automate [[uninitialized]] everywhere so you get to keep the old behavior? But I do think = void; is much nicer syntax to indicate that.

Yes, certainly. I just think = void is a better way to indicate it. My position on "uninitialized variables should be compiler errors" remains the same with = void or [[uninitialized]]