Date: Fri, 8 May 2026 18:19:20 +0200
> 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.
I don't think we can do anything about 'classic' private functions having
external linkage due to this little trick:
class MyClass {
MY_UNIT_TEST_FRIEND_DECLARATION;
};
I don't have evidence, but I have a feeling that this pattern alone is too
widespread to break.
Or did you have something else in mind?
Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> ezt írta
(időpont: 2026. máj. 3., Vas 23:38):
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
internal linkage, whether they are private extensions or not, so the symbol
table can be reduced and calls can become simpler and non-interceptible.
I don't think we can do anything about 'classic' private functions having
external linkage due to this little trick:
class MyClass {
MY_UNIT_TEST_FRIEND_DECLARATION;
};
I don't have evidence, but I have a feeling that this pattern alone is too
widespread to break.
Or did you have something else in mind?
Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> ezt írta
(időpont: 2026. máj. 3., Vas 23:38):
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
Received on 2026-05-08 16:19:38
