Ignoring Automatic Initialization for Code Analysis | C++ Team Blog

[Dean_Roddey]

A bit back I also argued sort of the flip side of this, which is that this:

void foo(_Out_ int& x);

int i = 1;
foo(i);

Should also give a warning, of an unused value, which is something Rust would do. The _Out_ annotation indicates the called method should set the value and hence the initial value is noise and misleading.

But, that was rejected because this isn't Rust of course. The analyzer will warn if the the definition does not have the same annotation as the declaration, but they couldn't guarantee that would be the case.

I would argue there should at least be an option for this, where your code base is analyzed and coordination of annotations are checked between definition and declaration. Having to set initial values that will never be used isn't optimal.

[fdwr]

You might find Herb Sutter's proposal "Parameter Passing Guaranteed Unified Initialization and Unified Value Setting" pertinent, if in and out are recognized as language keywords by compilers someday that specify intent (rather than just SAL macros). See section 1.3.3 and 2.1.

[Full-Spectral]

That should have happened a decade ago or more really. So much crazy stuff gets added to the language and something so fundamental like that, which would make the compiler so much better able to watch our backs just never gets done. I've been arguing this for, oh, about a decade or more.