If that's the direction you're thinking in, I have that worked out in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3716r1.html#How-to-subset
. With rationale on why it cannot change overload sets, targeting the SG23
profiles paper as soon as SG23 gets around to seeing it.

Example from paper:

[[profiles::remove(unsafe, "use std::string")]] char *strstr(const char *
haystack, const char *needle);

I hope to present it in SG23 soon for inclusion into the profiles paper.

Note that this has no overlap with the original proposal in this thread;
this is about making types/functions/constructs ill-formed in some cases,
the original post asked about marking a variable unreadable past a certain
point. In that regard, there should be somebody looking into what we could
do with a "move that marks it as poisoned after that point" construct - a
relocate construct.

Regards,
Peter

On Sun, Aug 9, 2026 at 10:35 PM 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.
>
>
>
>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>