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.

On Wed, Aug 12, 2026 at 11:16 AM Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I don't think that a new variable declaration should be allowed, it would
> be too confusing and ambiguous.
> Not only for the reasons we don't allow this today, but also as a
> consequence of the intended feature.
>
> The intention of the "redeclaration" feature is purely semantical in
> nature. We don't want any runtime effects out of the action of
> "redeclaring" a variable
> (with the exception of a potential address offset calculation in the case
> of inheritance or virtual inheritance, but let us ignore this case for now).
> No new objects should be created; no function or destructor/constructor
> should be called.
>
> Take for example the following code:
>
> int a = 1;
> double a = a;
>
> What does this mean? I would say the only thing it could mean is a cast
> from int to double and have the double shadow the int.
> Ok, now what about this?
>
> typeA_t a;
> typeA_t const a = a;
>
> Do I want to redeclare 'a' semantically? Or do I want to create a new
> object using a copy constructor passing in 'a' and have this new object
> shadow the original 'a'?
>
> We should opt for a way to express this idea without ambiguity. It must be
> done in a way as to make it clear that what we are expressing has only
> semantical consequences, and it cannot be anything else.
>
> Tiago
>
> -----Original Message-----
> From: David Brown <david.brown_at_[hidden]>
> Sent: Wednesday, August 12, 2026 09:52
> To: std-proposals_at_[hidden]
> Cc: Tiago Freire <tmiguelf_at_[hidden]>; David Brown <
> david.brown_at_[hidden]>
> Subject: Re: [std-proposals] A new C++ keyword: forget
>
> We could come a very long way with all this with three changes / additions
> to the language :
>
> 1. Allow a new variable declaration to shadow an exiting one, starting a
> new scope without having to open a new block. Thus :
>
> int a = 1;
> do_something(a);
> int a = 2;
> do_something_else(a);
> double a = 3;
> do_another_thing(a);
>
> would mean the same as :
>
> int a = 1;
> do_something(a);
> {
> int a = 2;
> do_something_else(a);
> {
> double a = 3;
> do_another_thing(a);
> }
> }
>
>
> 2. Allow declaring a variable of "void" type. Now "void a;" covers the
> OP's idea of "forget", since a variable of type "void" can't do much except
> have its address taken. Alternatively, we could have
>
> struct std::forget_t {};
>
> and then use "std::forget_t a;" to forget "a".
>
>
> 3. Keep the previous declaration "a" in scope while declaring the new
> "a". This is the difficult bit, because it changes existing behaviour.
> If this change can be achieved, then your "shadow(const) var;" becomes
> "const auto var = var;", and your "shadow(const A&) var;" becomes "const A&
> var = var;". To me, that syntax is a lot clearer.
>
> Most situations in which a declaration refers to the variable being
> declared use sizeof, since the value of the variable is not yet established
> and its use is UB (or erroneous behaviour). In C you have the common idiom
> :
>
> int * p = malloc(sizeof *p);
>
> Such code would have to keep its old effect (though it is not nearly as
> common in C++, for obvious reasons - including needing an extra cast).
> There is also the idiom of "int x = x;" as a way of disabling compiler
> warnings about use of "x" before initialisation.
>
> AFAIUI, what is currently not allowed in C++ - and therefore won't cause
> trouble with existing code - is referring to a type-deduced variable before
> initialisation. So "auto x = sizeof(x);" will not deduce "x" to be
> "size_t" - it is a constraint error. Thus "const auto var = var;" is
> currently invalid code, so this change would be backwards-compatible in any
> type-deduced context.
>
> That would not let you have the type-change, however - "const A& var =
> var;" does not involve type deduction. But you could write :
>
> const auto var = static_cast<A&>(var);
>
> The idea needs more thought to have a way that allows this change without
> affecting existing code and where it is clear to the programmer when the
> new declaration is referring to the previous declaration, and when it is
> referring to the current one.
>
> But I know I'd find these features convenient in my own code, if they were
> allowed.
>
> David
>
>
>
> On 11/08/2026 21:28, Tiago Freire via Std-Proposals wrote:
> > Hum, this could be useful if combined with other features.
> > Something that I want is to be able to make const a variable that is
> > originally not declared const.
> >
> > Maybe we could have a "shadowing" specifier, that could do that.
> >
> > Like
> > shadow(const) var; //makes var const for the remainder of the scope.
> > shadow(void) var; //makes var inaccessible
> >
> > I can also see the feature being used as.
> >
> > class A{};
> > class B: public A{};
> > B var;
> >
> > shadow(const A&) var; //var is still an object of type B but only
> > accessible as an object of parent type A.
> >
> > I'm not so sure about this last one.
> >
> >
> > ----------------------------------------------------------------------
> > --
> > *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on
> > behalf of Ville Voutilainen via Std-Proposals
> > <std-proposals_at_[hidden]>
> > *Sent:* Tuesday, August 11, 2026 9:13:23 PM
> > *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> > *Cc:* Ville Voutilainen <ville.voutilainen_at_[hidden]>
> > *Subject:* Re: [std-proposals] A new C++ keyword: forget
> >
> > On Tue, 11 Aug 2026 at 22:11, Henry Skoglund via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > > On 2026-08-11 21:05, Simon Schröder wrote:
> > > > This reminds me (in case you are continuing with the proposal):
> > You should discuss if once a variable has been poisoned, if the same
> > name can be reused for a different variable.
> > > Hi, once poisoned I think it should not be allowed to be reused. I.e.
> > > issue a compiler error like:
> > > double raw;
> > > forget raw;
> > > int raw; // <--- error: raw is forgotten and cannot be
> > resurrected
> >
> > Exactly. Make name lookup still find the name, but make it an error to
> > find a poisoned name.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://
> > lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
> >
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>