On Sunday, 3 May 2026 09:38:21 Pacific Daylight Time Rhidian De Wit via Std-
Proposals wrote:
> I personally prefer option 1, because I think that option 2 will result in
> a lot of *"Why can't I overload non-static class member functions?"* while
> it is allowed to overload PEM functions and since cppreference does not
> contain design considerations (which might actually be useful to link to
> the paper that proposed the feature) we might simply introduce a lot more
> confusion about very selective limitations of a feature, instead of just
> refusing function overloading.

I don't think we should limit the design options at all. Maybe compilers can
provide a warning that overload resolution changed, but even that might be too
much.

If someone violates ODR, that's their problem. There are tools to detect it.

> I like the idea of restricting a PEM to a single TU. The original idea for
> this proposal (as it seems to me at least) is that we don't want to expose
> helper functions in a header and polluting the header with potentially
> extra includes and symbols.

That's an impossible ask. You can't tell whether the extra declarations are
present in a single TU or more than one. To ask for that would be to introduce
another form IFNDR situation.

If anything, discuss whether those private extension functions shall always
have internal linkage or not. In fact, I'd welcome a discussion on whether
private functions could have internal linkage, whether they are private
extensions or not, so the symbol table can be reduced and calls can become
simpler and non-interceptible.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.