Sure, sometimes the code structure below is better. I actually have
something along those lines in my current project. This is the same
regardless of whether the new variables have the same name with my
proposed changes, different names, or equivalent nested scopes.

A key point here is that in the first version, the earlier "a" variables
do not end their lifetimes after they are shadowed by the new "a"
variables. Their destructors are called at the end of the function, in
reverse order of creation, which means the variables and their space
will likely have to hang around until that point.

If there are no (non-trivial) destructors involved, then a compiler is
free to re-use the resources of the first "a" when creating the next
one, and so on.

David



On 12/08/2026 10:02, Sebastian Wittmeier via Std-Proposals wrote:
> Sometimes the scopes are better set differently than just long an inner
> scope:
>
> class Heavy; // needs resources
>
> class, heavy2;
>
> Heavy a = 1;
> do_something(a);
> Heavy2 a = 2;
> do_something_else(a);
> Heavy a = 3;
> do_another_thing(a);
>
> {
>
> Heavy a = 1;
> do_something(a);
>
> }
> {
> Heavy2 a = 2;
> do_something_else(a);
> }
>
> {
> Heavy a = 3;
> do_another_thing(a);
> }
>
> What I mean is, redefinition could lead to a FIFO like order of
> destruction or be an early drop. Think of a std::variant which is
> assigned a new value and type. It destrucs the previous object before
> assigning a new one.
>
> -----Ursprüngliche Nachricht-----
> *Von:* David Brown via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 12.08.2026 09:52
> *Betreff:* Re: [std-proposals] A new C++ keyword: forget
> *An:* std-proposals_at_[hidden];
> *CC:* David Brown <david.brown_at_[hidden]>;
> 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
>
>