I can see a problem with constructor approach. There will be:

1. Zero-abstraction-cost way for data in - normal constructor, taking
e.g. naked pointer

2. Zero-abstraction-cost way of relocating data - e.g.
"A(std::relocates, A* ptr)"

3. But it lacks zero-abstraction-cost way of data out - at the end,
there is always a need to set pointers to zero and call destructor to do
nothing


So any constructor approach will be somewhat incomplete, not covering
whole lifetime of data.

The only way to elide spare destructor calls I can imagine, is to create
kind of "moving out destructor", that replaces default one. So that's
why I prefer destructor :)


PS. Seems I have some problem with discussion list, I hope this message
will be delivered correctly.


On 2021-02-12 18:41, Edward Catmur wrote:
> That's a very interesting use case, but it could easily be
> accommodated in other proposals, e.g. in N4158 by allowing the two
> arguments to be of different types.
>
> The reason I think that a constructor syntax is to be preferred is
> that it's more difficult to set up class invariants than it is to
> leave a class's members in a state where the destructor can be elided
> without a leak. For instance, what happens if someone adds a
> std::string member to your type? - under a constructor-style proposal,
> a member that is not explicitly initialized in the
> mem-initializer-list can be automatically initialized by destructive
> move from the corresponding member on the other instance (of the same
> type).
>
> On Fri, Feb 12, 2021 at 12:43 PM Maciej Polanski via Std-Discussion
> <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>> wrote:
>
>
> On 2021-02-11 20:02, Edward Catmur via Std-Discussion wrote:
> > This would operate very similarly to the current proposal, but with
> > the possibly unintuitive difference that the new object is being
> > passed as the parameter, so that e.g. ~c(x.c) initializes x.c
> with the
> > value of c. Furthermore, it would require re-inventing syntax to
> allow
> > for move construction of subobjects.
>
> While approaches "Constructor that destructs its argument" and
> "Destructor that constructs its argument" seems to be just
> symmetrical,
> my DestrcutorConstructor would have one more feature: it allows
> "destructing move" depositing object's data in object of other
> class, or
> even a function.
>
> So without judging if this is worth efforts or not, I'd like to
> highlight this part of my proposal:
>
> //------
> // class to receive data from object being deleted
> class cDataSink {
> public:
> TakeOverData(cSomeData*);
> }
>
> // class that can be deleted with real zero-additional-cost
> transfer of
> data:
> class C {
> cSomeData *pDdata;
>
> public:
> ~C(cDataSink* sink) { sink->TakeOverData(data); } // <-
> DepositingDestructor here
> ~C() { delete pData; } // Normal
> destructor
> };
> //------
>
> Regards,
> Maciej
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> <mailto:Std-Discussion_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion>
>