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

> On 12 Aug 2026 12:32, Simon Schröder via Std-Proposals wrote:
> > I think a better reason to disallow reusing variable names is
> > maintainability. Suppose we have a long function (I know we shouldn't,
> > but everybody has at least one of these) with a variable declaration at
> > the top and its last use at the bottom. Now, if I redefine the variable
> > with the same name but a new type somewhere in the middle (I thought it
> > wouldn't be used below this point), suddenly my program might do
> > something totally unexpected (it's a logic bug). However, if I just
> > forget/poison/redact the variable name I get a compiler error. Getting a
> > compiler error is acceptable, silently accepting different behavior is
> not.
>
> I'm not sure I buy this use case.
>
> First, if the example is that a programmer forgets (no pun intended) or
> misses that a variable that is declared at the beginning of this long
> function is used at the end and clobbers it in the middle then he might
> as well forget to "redact" it in the middle.

It's okay if he forgets to redact it in the middle. Redactions are for your
own safety in order to not continue using a variable.

> And actually, he couldn't
> redact it as he would not be able to use the variable in the end, so
> this example doesn't work.
>
That's the whole point: Redacting the variable is an error when it is still
used later. It is okay if during maintenance I wrongfully redact a variable
name because the compiler will tell me that it is an error. Then I have to
fix my changes by removing the redaction. That's my example: I make a
change that breaks my code and I get an error. I think this behavior is
desired.

>
> If the example is that the variable that is declared and used at the
> beginning of the function is then being redeclared later. That would be
> a compile-time error currently, so no redacting needed. Furthermore,
> redacting doesn't help, as it would prohibit using this name again -
> presumably, until the end of the function? Or scope? Or TU?

This particular example is about discussion to allow reusing a variable
name after a redaction (or in general). If we allow redaction, the question
arises if we should allow or forbid reusing the variable name. This is my
point that we should forbid it! Because the programmer might miss a later
use of the variable when reusing a variable name. In contrast to the
example above where only redaction is allowed (with no reuse of a variable
name), in this case if we would allow it, the code would silently change
and the compiler cannot give an error.

> Either way,
> the compilation error is not fixed and the user still has to invent a
> new name for the variable. And also it isn't clear who is supposed to do
> the redacting and what for (is it the one who wrote the original code
> with the variable at the beginning of the function or the one who is
> adding the second variable later - none of these programmers have a
> reason to redact anything).
>
> [...]
>
> I think, the OP needs to reconsider the intended use case of this
> feature, accounting for the fact that not all of the compiler code may
> be under the control of the programmer. If the intended use case is
> limited to just avoiding name clashes within the function scope, I
> think, a way of "undeclaring" or "shadowing" a variable declaration
> after a certain point (with the ability to reuse the variable name)
> would be more appropriate and useful.

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).

> If the intended use case is to
> affect some more global TU state, then the feature becomes increasingly
> more controversial and less useful, IMO.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>