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.