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