Hi Jeremy, nice comprehensive overview. To complete   What if the motivation is to prevent use, when it is not needed anymore.  - Reasonably long function / scope block {}.  - no reuse of identifier  - lifetime should go until end of block scope  - but it should be prevented that the user (programmer) accesses it   So similar in idea to the first 'mutable', now const, which Jarrad mentioned earlier today.   -----Ursprüngliche Nachricht----- Von:Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 10.12.2025 17:02 Betreff:Re: [std-proposals] [PXXXXR0] Add a New Keyword `undecl` An:std-proposals_at_[hidden]; CC:Jeremy Rifkin <jeremy_at_[hidden]>; Hi, It is extremely unlikely something like this would ever be added to C++. Such a change would require a lot of motivation, and this paper doesn't currently provide much motivation.  If the motivation is reusing the name, consider what rust has done with shadowing: let x = foo(); let x = x.transform(); // new x shadows old x, can be a new type There is precedent for this mechanism in C++ now with P2169.  If the motivation is compiler optimization, this is a micro-optimization and would be harmful as a language feature. Compilers can very easily identify when objects in a function are dead and reclaim storage and registers.  If the motivation is ending an object's lifetime as far as the C++ abstract machine is concerned and calling destructors, just use std::optional: std::optional<T> thing; ... thing.reset(); // destroy the object, call the destructor This is much more simple and straightforward to reason about than the language feature you're proposing. If you are concerned about the overhead from the flag std::optional stores to indicate if a value is contained or not, this is something compilers should be able to optimize with relative ease, though the overhead would be completely negligible in almost all cases even if it didn't.  Cheers, Jeremy