On Sat, 12 Jun 2021, 20:13 Antoine Viallon via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:


12 juin 2021 16:49 "Tom Honermann via Std-Proposals" <std-proposals@lists.isocpp.org> a écrit:

In either case, I think there is a need to be able to propagate poison/taint.


I know it might sound dump, but, like what we do with the nullptr keyword, wouldn't a new keyword, like "undefined" for instance, be the best solution for that?
If a variable has this pseudo-value, it means to the compiler that it is uninitialized, and appropriate warnings can be fired if the compiler can prove a variable with the "undefined" value is being used.
It would only have effects during compilation, and would be completely "removed" during runtime.

What do you think?

What does it mean to prove that an uninitialized value is used? There may be some input on which the value will be used, but the program may be part of a larger system which guarantees that input is not encountered. 

Actually, we want runtime effects; at least 3 distinct effects. In secure mode, we want a specific value to be loaded in place of the uninitialized value; in debug mode, the program should terminate with a runtime diagnostic; in release mode we want the optimizer to assume that use of the uninitialized value cannot occur.