On Wed, Aug 12, 2026 at 4:41 PM Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 12 Aug 2026 16:26, Simon Schröder wrote:
> >
> >
> [...]
> >
> > And this was the point I was trying to make: "with the ability to reuse
> > the variable name" might be a bad idea because then you can change the
> > behavior of the program by mistake without an error by the compiler. If
> > we only allow redaction and it was a mistake, there will be an error
> > (that can easily be fixed by removing the redaction).
>
> Can you provide an example where undeclaring a variable would silently
> change code behavior and not cause a compilation error?
>
> It's probably a contrived example, so you have to imagine a more
complicated and longer function in the real world.

Assume that the following is the original code:
auto myFunction()
{
    double x = std::sqrt(2.0);
    // lots of other code
    return x;
}
Then someone comes in and does a few additions:
auto myFunction()
{
    double x = std::sqrt(2.0);
    // some of the previous code
    redact x; // redact the variable because the programmer assumed that it
wasn't used anymore
    int x = 42; // if we allow reuse after redaction: maybe I just redacted
the variable to reuse the name
    // some more of the previous code (and probably also a use of the new
'x')
    return x; // no compiler error here, but changed behavior
}

Compilation after the changes were done cannot catch that the type of 'x'
in the return statement has changed. We would need a rule for the
programmer that after every redaction you need to recompile to make sure
the redaction was valid. Only after you have made sure that the redaction
is valid can you reuse the variable name. But it is not a rule that can be
enforced by a compiler (maybe an IDE could track the changes).

>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>