C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Translation-unit-local functions that access private class fields

From: André Offringa <offringa_at_[hidden]>
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.
>

Received on 2026-04-29 11:46:21