I had time to think, and I have many thoughts.
This will be a long email. Sorry. You have been warned.

We seem to be getting more and more into implementation details.
Maybe we should move this conversation elsewhere to not spam the mailing list?
Is this fair use or abuse?


I. Multiple Approaches

It is obvious that we all come from different backgrounds.
Upon reflection (pun intended) I realized what's different about my approach.
I seem to favor solutions with "nice properties" and I preach about the "identity" of a class, while You just want to define a damn private function.
My approach is very much a "mathematician's approach" (I am one), while Your approach is much more "practical".
Probably the best solution (if such a thing exists) lies somewhere in between.
I just want to say, I represent one extreme, and I am aware of that.

We seem to have two main approaches, one with "reopening the class private scope" and one without, and so far I am not convinced that any one is better than the other.
I do have a preference, but only because I played around with it more than the other approach.
I propose that we explore and describe both.
There may be more we haven't thought of yet.
We don't need to agree on any one unanimously.
We can present more than one in the first proposal.
We only need to be thorough and extensive.


II. Next Steps

I get the impression that it is *very* difficult to get anything new into the C++ standard.
Surely a core language feature proposal will be submitted to a lot of criticism from all angles.
Therefore we should try to anticipate as many arguments as we can.
So far I haven't seen any red flags that the core idea (hiding non-ABI relevant private members) would clash with the core principles of C++, but how can we be sure?

I also thought about creating a short questionnaire we could send out to the C++ community to gauge reception of the various approaches.
I realized, I am not the "average C++ programmer".
I would love to see real data on what syntax/ruleset they think is confusing or clear, stuff like that.


III. Thoughts on ODR violation and overload resolution

Current class member functions have a nice property; it doesn't matter where we put the function body, because all member functions are declared upfront, member function calls always resolve the same way, e.g.


// Header
class MyClass {
public:
    void Bar() { Foo(3); } // calls Foo(int)
    void Foo(double);
private:
    void Foo(int);
};
// .cpp
void MyClass::Foo(int) { ... }
void MyClass::Foo(double) { ... }


is exactly the same as


// Header
class MyClass {
public:
    void Bar();
    void Foo(double);
private:
    void Foo(int);
};
// .cpp
void MyClass::Bar() { Foo(3); }
void MyClass::Foo(int) { ... }
void MyClass::Foo(double) { ... }


Let's turn Foo(int) into a hidden private function:


// Header
class MyClass {
public:
    void Bar() { Foo(3); } // calls Foo(double)
    void Foo(double);
};
// .cpp
private void MyClass::Foo(int) { ... }
void MyClass::Foo(double) { ... }


It is clear that the inline Bar() must not invoke Foo(int) to avoid ODR violation.
But now if we move the definition of Bar() out of the class:


// Header
class MyClass {
public:
    void Bar();
    void Foo(double);
};
// .cpp
private void MyClass::Foo(int) { ... }
void MyClass::Foo(double) { ... }
void MyClass::Bar() { Foo(3); } // calls Foo(int) now? It didn't before...


AND we allow Bar() to invoke Foo(int), then we break the "nice property".
It wouldn't be an ODR violation, but it opens the door to sneaky bugs and unexpected function calls because we (C++ programmers) are already accustomed to the way classes work today.
Is this inherently bad? Well no, free functions already work like this:


void Foo(int);
void Bar() { foo(3.2); } // Calls Foo(int)
void Foo(double);

// Versus

void Foo(int);
void Foo(double);
void Bar() { foo(3.2); } // Calls Foo(double)


but I feel like this would be a step backwards in terms of language safety and bug prevention.
It would also increase mental load.
Instead I propose that hidden private functions are not visible to name lookup/overload resolution by default, e.g:


// Header
class MyClass {
public:
    void Bar();
    void Foo(double);
};
// .cpp
private void MyClass::Foo(int) { ... }
void MyClass::Foo(double) { ... }
void MyClass::Bar() { Foo(3); } // calls Foo(double)


Bar() should call Foo(double) because it would call Foo(double) if it was inlined.
I propose that hidden private functions must be invoked with a special syntax, e.g.


void MyClass::Bar() { private Foo(3); } // Looks a bit weird though
// OR
void MyClass::Bar() { this->private Foo(3); } // A little better


This is very similar to template disambiguation syntax:


auto l = []<class>(){};
l.template operator()<int>();


For convenience, we could introduce a new using statement:


// .cpp
private void MyClass::Foo(int) { ... }
void MyClass::Foo(double) { ... }
void MyClass::Bar() {
    using private; // Introduce all hidden private entities for name lookup/overload resolution
    Foo(3);
}


This can work with constructors as well:


private MyClass::MyClass(int) { ... }
MyClass::MyClass() : private MyClass(42) { ... }


Also, I feel like we should allow hidden private default constructors too.
There's nothing special about them.
If there's already an implicitly defined one, that's a compiler error.

While we are here, IMO this syntax would be nicer when put next to other member functions:

void MyClass::private Foo(int);
void MyClass::Bar() { ... }
void MyClass::private Foo(int) { ... }


IV. Should hidden private functions have internal or external linkage by default?

Given the option, I feel like internal linkage would be chosen in 99% of the cases, but we should not jump to conclusions just yet.
Sometimes the implementation of a class is broken up into multiple .cpp files, and we should support this use case too.
What do you think about this: