I think that the programmer should have the way to hide the implementation details, otherwise the main concept of OOP is not provided by the language.

It works in c++ when we have a plain function, but the same feature is not available for the class methods.
A forward declaration of the plain function has the same NDR problem, but it is allowed. Anyway the linker fails in case of tipo. This is right for the class methods as well.

I can propose an alternative method of the interface declaration.
Suppose we have the class extension functions like in c#. These functions are declared outside of the class and they are the class interface. I am not sure, if the extension functions is something that will be available soon, but I am absolutely sure, that it will be the first usage of this feature, because, as I said previousely, the hiding of the implementation details is lack in the language.

My first proposal of method declaration outside of the class is much simpler and similar to another feature that already presents in the language - the plain function declaration.

On Thu, Aug 26, 2021, 00:25 Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, Aug 25, 2021 at 3:47 AM Valery Osheter via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> As for your proposal, I see that it requires more syntax changes, and as a result, it seems to me that there is less chance of being approved.

That really should not be the focus of your proposal. The syntax you
use to create it is less important than the *utility* of what you're
creating. And resistance is going to be based more on whether it's
legitimately useful in the form you're proposing it, questions about
implementation difficulty, and looking at how complete the proposal

For example, one *really* important question that you don't bring up
is this: what happens if you have one TU that has this
forward-declaration for members, and one TU that defines the type, but
the second TU never sees that forward-declaration? That's rather
important, since you say that if the eventual definition doesn't match
up with the forward declaration with all of its members, then it
should error out.

But that can't really happen *after* the compiler is done with the
type. The standard way to handle this is to say that it's a violation
of the ODR and therefore is il-formed, no diagnostic required (NDR).
That's acceptable currently because the standard way people declare
classes is to have a single file that provides the full definition of
that class. Two different users of a class simply include the same
header; they're not having to each type the class definition

This becomes a lot less viable when you have multiple files that each
may have partial definitions, and the actual definition needs to match
up with them. From a practical perspective, NDR is *really* bad here.
It's way too easy to accidentally violate ODR with these things (a
simple typo can do it), and it would be exceedingly helpful if ODR
violations were diagnosable. Indeed, I might go so far as to say that
if it's possible to have these partial declarations and *not* diagnose
when they fail to match the definition, then we probably shouldn't do
Std-Proposals mailing list