On Wednesday, April 29th, 2026 at 3:35 PM, Ell <ell.ell.se_at_[hidden]> wrote:

> On Wednesday, April 29th, 2026 at 2:46 PM, André Offringa via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> >
> > On 4/29/26 09:18, Sebastian Wittmeier via Std-Proposals wrote:
> >
> > > body { font-family: Arial, Verdana, Sans-Serif ! important; font-size: 12px; padding: 5px 5px 5px 5px; margin: 0px; border-style: none; background-color: #ffffff; }p, ul, li { margin-top: 0px; margin-bottom: 0px; }
> > >
> > > 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.
>
> That seems like the only reasonable option. Otherwise member functions would have
> to see the entire TU.
>
> > Though if Foo were a templated class and instantiated after F(int) is available, F(int) would participate in overload resolution.
>
> It wouldn't. During instantiation only ADL is performed (and only for dependent
> calls) which never finds member functions (MSVC famously used to get two-phase
> lookup wrong, but they fixed it when targeting C++20 I think).

... but on second thought it *would* find F(int) if the call was spelled `this->F(5)`
instead, even without an in-class overload (for example, when F is expected to come
from a base class), so this is still a problem.