"re-using variables does make code reviews more difficult/time-consuming,
we're only human..."

NOT, when it is the same object and you are just restricting access to it

also creating to many superfluous aliases from not shadowing in these safer
caes makes code reviews worse


On Thu, Aug 13, 2026 at 6:13 PM Jonathan Grant via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 12/08/2026 15:40, Andrey Semashev via Std-Proposals wrote:
> > On 12 Aug 2026 16:26, Simon Schröder wrote:
> >>
> >>
> >> On Wed, Aug 12, 2026 at 12:55 PM Andrey Semashev via Std-Proposals <std-
> >> proposals_at_[hidden] <mailto: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.
> >
> > My point here is that the redaction doesn't give you anything, and
> > therefore I don't see the point of adding it. It doesn't prevent any
> > errors that would not be prevented without it, and it doesn't provide
> > new functionality that is not currently available.
> >
> >> 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.
> >
> > Whether a variable is "redacted" (i.e. the name is permanently banned)
> > or "undeclared" (i.e. its name is made no longer reserved after the
> > object and made available for new declarations), its usage will generate
> > compilation errors anyway.
> >
> >> 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).
> >
> > Can you provide an example where undeclaring a variable would silently
> > change code behavior and not cause a compilation error?
> >
> > I think, variable undeclaration, with the ability to reuse the name
> > afterwards, adds a useful feature: it allows for reusing commonly used
> > names for different purposes instead of having to enforce scopes or
> > invent unique names. I often want to reuse short names like p, i, it, e,
> > end, etc. in one function, and I could see myself using variable
> > undeclaration to achieve that. OTOH, I don't see myself wanting to
> > redact (i.e. permanently ban) a name.
> >
>
> re-using variables does make code reviews more difficult/time-consuming,
> we're only human...
>
> Kind regards, Jonathan
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>