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_at_[hidden]> wrote:

> On Wed, Aug 25, 2021 at 3:47 AM Valery Osheter via Std-Proposals
> <std-proposals_at_[hidden]> 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
> is.
>
> 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
> themselves.
>
> 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
> it.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>