In case of PIMPL you have to wrap each interface method. My proposal requires only to declare methods. Does it not make the forward method declaration attractive to people?
It does not allow to create the instance of the class as PIMPL does, but except that it allows to write all tests of the class and to do it directly without a PIMPL intermediary. Note that the implementation class must be defined at the place PIMPL creates its instance. This is the same as in my method, the object creation requires the class to be defined anyway.

On Thu, Aug 26, 2021, 20:48 Jason McKesson via Std-Proposals <> wrote:
On Thu, Aug 26, 2021 at 1:26 PM Thiago Macieira via Std-Proposals
<> wrote:
> On Thursday, 26 August 2021 08:08:07 PDT Valery Osheter wrote:
> > I agree with you that I failed to convince people. This is because of my
> > insufficient experience and poor English.
> >
> > I am ready to answer any relevant question, but I see I cannot make
> > progress. If someone wants to continue with it, then I really wish good
> > luck, and I will support him. I thank everybody who interested and
> > participated.
> You have not failed to convince people that this is an interesting idea.
> You have failed to write a compelling proposal that will make it through the
> EWG and CWG in the committee.

I've also realized that there's a rather big flaw with this approach,
which leaves PIMPL as the only recourse.

When you have a type that employs PIMPL, there are actually a lot of
things you can do with it. You can allocate and deallocate them. You
can treat them like any other type. It's up to the PIMPL
implementation to allocate and manage the pointer to the private

This proposal can't do that. You can only use a pointer/reference to
the type; you can't make one yourself. And there are lots of cases
where you want to keep the implementation private while still allowing
users to create and destroy such objects.

So thinking more on it, I'm not sure how useful this would be in general.
Std-Proposals mailing list