Date: Thu, 26 Aug 2021 13:48:02 -0400
On Thu, Aug 26, 2021 at 1:26 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> 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
implementation.
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_at_[hidden]> 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
implementation.
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.
Received on 2021-08-26 12:48:16