Date: Wed, 29 Apr 2026 13:46:17 +0200
On 4/29/26 09:18, Sebastian Wittmeier via Std-Proposals wrote:
> AW: [std-proposals] Translation-unit-local functions that access
> private class fields
>
> Hi André,
>
> I think you got the point itself.
>
> As Thiago pointed out, it does not have to be necessarily templates.
>
> It probably is enough, if the member function is defined inside the
> header file, e.g. directly within the declaration of the class or
> marked as inline.
>
> Then overload resolution could differ even for calls (to private
> member functions) within the class.
>
Not sure I understand. Is this what you mean?
class Foo {
public:
Foo() {
F(5); // Calls double overload
}
private:
void F(double) { }
};
private void Foo::F(int) { }
As I'm trying to word it in the proposal, the call to F would resolve to
the double overload because F(int) is not yet declared at that point.
Though if Foo were a templated class and instantiated after F(int) is
available, F(int) would participate in overload resolution. I don't
quite understand why you refer to this as ODR violations ?
Regards,
André
> Currently there are already possible ODR violations for calls outside
> the class, if a different (e.g. free) function is called.
>
> Internal linkage, which should protect the class encapsulation could
> give the wrong picture about those private extension functions.
> Shifting the image from unique and declared upfront per class to
> declared per TU and not only private in the class, but also exclusive
> to the TU.
>
> The mental picture should still be that all private functions are
> clearly separate from each other (even over several TUs). And if they
> have the same name/signature, then they should not be called by any of
> the functions defined in a header file: templates, functions defined
> in the declaration and inlined functions.
>
> AW: [std-proposals] Translation-unit-local functions that access
> private class fields
>
> Hi André,
>
> I think you got the point itself.
>
> As Thiago pointed out, it does not have to be necessarily templates.
>
> It probably is enough, if the member function is defined inside the
> header file, e.g. directly within the declaration of the class or
> marked as inline.
>
> Then overload resolution could differ even for calls (to private
> member functions) within the class.
>
Not sure I understand. Is this what you mean?
class Foo {
public:
Foo() {
F(5); // Calls double overload
}
private:
void F(double) { }
};
private void Foo::F(int) { }
As I'm trying to word it in the proposal, the call to F would resolve to
the double overload because F(int) is not yet declared at that point.
Though if Foo were a templated class and instantiated after F(int) is
available, F(int) would participate in overload resolution. I don't
quite understand why you refer to this as ODR violations ?
Regards,
André
> Currently there are already possible ODR violations for calls outside
> the class, if a different (e.g. free) function is called.
>
> Internal linkage, which should protect the class encapsulation could
> give the wrong picture about those private extension functions.
> Shifting the image from unique and declared upfront per class to
> declared per TU and not only private in the class, but also exclusive
> to the TU.
>
> The mental picture should still be that all private functions are
> clearly separate from each other (even over several TUs). And if they
> have the same name/signature, then they should not be called by any of
> the functions defined in a header file: templates, functions defined
> in the declaration and inlined functions.
>
Received on 2026-04-29 11:46:21
