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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>