With the recent support of explicit object parameter functions, inheriting explicit object member functions from base class seems to work except for post increment operator 'operator++(int)'. struct add_fn { template <typename Self> Self operator++(this Self&& self, int) { auto temp = self; ++self; return temp; } }; struct A : add_fn { int n; A(int n) : n(n) {} A& operator++() { ++n; return *this; } // this doesn't work either: // A& operator++(this A& self) // { // ++self.n; // return self; // } }; int main() { A a { 5 }; ++a; // ok a++; // error: no 'operator++(int)' declared for postfix '++' } godbolt link: https://godbolt.org/z/1h57Thvds
I believe this is correct behaviour: The definition of `operator++` in the child class hides the `operator++` declared in the base class. Similarly to the following code: struct base { void f(int) {} }; struct d1 : base { void f() {} }; struct d2 : base { using base::f; // explicitly add base::f as an overload void f() {} }; int main() { d1{}.f(10); // error d2{}.f(10); // OK }
(In reply to Nathaniel Shead from comment #1) > I believe this is correct behaviour: The definition of `operator++` in the > child class hides the `operator++` declared in the base class. Similarly to > the following code: > > > struct base { > void f(int) {} > }; > struct d1 : base { > void f() {} > }; > struct d2 : base { > using base::f; // explicitly add base::f as an overload > void f() {} > }; > > int main() { > d1{}.f(10); // error > d2{}.f(10); // OK > } I'm pretty sure Nathaniel is right, https://godbolt.org/z/d4r3dTsqa https://godbolt.org/z/sxz1rcGbb Mind you, clang and msvc's implementations are buggier than mine so I'm not going to say "doesn't work on theirs so it isn't a bug" but I don't think this one is a bug. Thank you for testing my patch though, I do appreciate it.
I meant to post this link instead of one of the others. https://godbolt.org/z/oMP8185Yh I guess I shouldn't be replying to things while still waking up, sorry!
Yes, I think gcc is correct here. Explicit object functions aren't immune to name hiding.