I think there were two other feature proposals disallowing using variables from some point in time. One was using relocation to relocate from the variable. So the compiler knows from this moment on (including in loops) it is no longer allowed to access the variable. The other was some drop feature (rest: citation): -----Ursprüngliche Nachricht----- Von:Simon Schröder via Std-Proposals <std-proposals_at_[hidden] <mailto: std-proposals_at_[hidden]> > Gesendet:Do 24.07.2025 10:00 Betreff:Re: [std-proposals] Similar to [[no_discard]], but store in a variable, maybe call it [[must_store]] An:std-proposals_at_[hidden] <mailto: std-proposals_at_[hidden]> ; CC:Simon Schröder <dr.simon.schroeder_at_[hidden] <mailto: dr.simon.schroeder_at_[hidden]> >; On Tue, Jul 22, 2025 at 3:48 PM Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:   It does, what it should. Is it short? Is it pretty? Not sure. Scopes work in a lot of cases. However, the ideal solution might be overlapping scopes in some cases.  I want to bring back an idea from Rust: It has a drop() function which will call the destructor of an object immediately (and thus officially ends the lifetime of an object). It better states the goal of ending the lifetime explicitly than nested scopes.  I would say that drop() is longer than scopes (at least number of keystrokes), but it is one less line to read. Maybe it is not short, but it is concise. And I would claim it is much prettier than scopes.   -----Ursprüngliche Nachricht----- Von:Henry Skoglund via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Di 11.08.2026 19:59 Betreff:Re: [std-proposals] A new C++ keyword: forget An:std-proposals_at_[hidden]; CC:Henry Skoglund <henry_at_[hidden]>; On 2026-08-10 19:06, Udo Steinbach via Std-Proposals wrote: > Reason? Benefit? Use case? > > I get the impression that more and more people here want to add yet > another safety belt for every conceivable scenario—one that’s supposed > to protect the user from something, but which the user has to fasten > themselves. Benefit: Zero. If a security mechanism works only by > introducing another protocol that must be followed manually, the > benefit is negative. On 2026-08-10 14:26, Ville Voutilainen via Std-Proposals wrote: > On Sun, 9 Aug 2026 at 23:35, Jarrad Waterloo via Std-Proposals > <std-proposals_at_[hidden]> wrote: >> Concerning voiding/deleting/forgetting/poisoning/shadowing specific overloads, it has to do with "safe subset of a superset" not just at the language level but at the library level. >> I use an undesired overload to first create one or more functions that I do want and then I hide the undesired function to prevent me from using it further. >> >> #include <some-std-library> >> #include <3rd-party-utility-library-that-uses-that-std-library> >> #include <hide-portions-of-std-library> // NOTE: order matters ... consider all one gains by easily copying 3 lines of code >> >> ... >> >> While there are cases where proxying is necessary, this could be a good/easy alternative because it allows one to remove specific overloads without having to proxy an entire library. >> >> Consider this hyper specific example, >> >> Instead of creating a non invalidating view of a vector, or any class really, which requires creating a new type and duplicating all of the desired overloads and transitive dependencies, while omitting all of the undesirable overloads, one could just hide the methods that invalidate from one's own code. >> >> Here is another use case, with all of the safe operations that can be performed on std::optional<T> do I really want access to the less safe operations. >> >> This isn't just a per programmer tool but has to do with standards that team leads enforce upon their teams to improve code quality. > I'm not convinced it's the best of ideas to bring wishes for > controlling overload resolution into this discussion. > Being able to say that a name is poisoned for name-lookup for the > remaining scope is seemingly very reasonable, and has very > clear example use cases (like poisoning the name of a moved-from > entity). Overload resolution control is something quite different, > and probably wouldn't share the property of allowing the uses before a > certain point but not after, and would likely be just "don't > allow certain uses at all in this scope). While it could be argued > that that's just a matter where you place the poisoning, there's > also the matter that such overload poisoning would be better done in > scopes wider than a function block scope, like per-namespace > or per-class. Or even per-TU. It's eerily close to a proper profile, > and poisoning name lookups for individual variables seems less so > to me. I can of course be convinced otherwise, this is not a final > analysis conclusion, just a current take. Thanks for all the replies! Re. use case: say you have a reasonably large (and old) codebase with a function: void munge(double raw) {    auto cooked = raw * tweakfactor; ... the cooked chap is used in the rest of the function, until a revision comes along and adds some code at the end:    auto newvalue = raw; ... This new code shouldn't have picked up on raw, it should have used cooked. I've been bitten a few times by these kinds of bugs so I wanted some way to cause an error, first idea was some kind of function template:     auto cooked = std::burn_after_reading<raw> * tweakfactor; I didn't know about the poison #pragma (until now), I like that term "to poison" it's very succinct :-) And that's what I wanted the template to do. I couldn't figure how, though. So instead I came up with the idea of the "forget" keyword. Then as a cherry on top, I realized you can reuse that "forget" keyword to being able to abolish *all* uses of say strcpy() inside a TU, regardless if the forget statement arrives before or after any strcpy() calls. I.e. a way to blacklisting a function. Maybe there's also some benefit of being able to poison types? E.g. forget MyType, std::string; or forget ::;  // poisons everything, scary... Rgrds Henry -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals