C++ Logo

std-proposals

Advanced search

Re: [std-proposals] A new C++ keyword: forget

From: Andrey Semashev <andrey.semashev_at_[hidden]>
Date: Wed, 12 Aug 2026 17:40:45 +0300
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.

Received on 2026-08-12 14:40:56