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.




On Sun, Aug 9, 2026 at 3:35 PM Simon Schröder via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> In the case of the for-loop I guess this could be replaced by a while-loop
> with a lambda function using a static counter variable. It‘s not the nicest
> solution, but it could work.
>
> The question then is, what are the real use cases? In many cases we could
> use scopes (and the lambda trick in a few other cases). The only
> disadvantage of scopes is that overlapping scopes don‘t work. However, how
> many use cases are there?
>
> You could also start a new scope and introduce the same variable name to
> hide the one from the outer scope. Maybe even make that variable
> [[indeterminate]]. (Does the compiler properly catch that?) Bonus points if
> you introduce a special type that cannot be accessed. Only downside: this
> quickly leaves us with too many nested scopes! (If I would follow that
> design I might not indent those scopes.)
>
> I‘m not sure if ‘forget’ is the correct word here. Maybe ‘hide’?
> Inaccessible? Maybe we could use an attribute? The only downside of an
> attribute would be that checking is not mandatory for all compilers (but
> the program would be ill formed if the variable is read after that).
>
> BTW, you said you want to forbid reading. Does that mean we could have
> write-only variables? (This to me would be an interesting thought. Though I
> don’t have any specific example in mind where this would be useful.)
>
> > On Aug 9, 2026, at 6:29 PM, Henry Skoglund via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > Hi, for a long time now in C++ we have the const keyword, which
> disallows writing over a variable.
> >
> > What if we also want to disallow *reading* a variable?
> >
> > One way is to hide it inside a dummy compound statement, like when
> you're inside a switch statement:
> >
> > ... break;
> > case 42:
> > {
> > int helper = x + 42;
> > ...
> >
> > but consider a for loop:
> > for (int i = 0; (i < 42): ++i)
> > {
> > }
> > no easy way to disallow reading that i variable inside the for loop.
> > Same problem also for argument(s) to a function, when inside the
> function body.
> >
> >
> > Introducing the c++ forget keyword
> >
> > This lets you specify variables, types or functions that you want to
> forget/hide in the current scope. E.g. the for loop:
> > for (int i = 0; (i < 42): ++i)
> > {
> > int b = i * i; // ok
> > ...
> > forget i;
> >
> > int c = i / 7; // compiler error: i is forgotten and cannot be used
> > }
> >
> > Forgetting a variable does not affect destructors, they run as normal.
> I.e. the forget keyword is only a compile time thing.
> >
> >
> > You can also forget your least favorite parts of the C++ library, e.g.
> > forget strcpy(char*, const char*);
> >
> > so that you'll get a compiler error whenever you try to use strcpy() in
> a TU.
> >
> > Best regards Henry
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > 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
>