Please, add member function example!

Pretty much ...

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



On Sun, Aug 9, 2026 at 4:53 PM Peter Bindels <dascandy_at_[hidden]> wrote:

> 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
>>
>