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 <> 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 {

// class that can be deleted with real zero-additional-cost transfer of
class C {
     cSomeData *pDdata;

     ~C(cDataSink* sink) { sink->TakeOverData(data); }    // <-
DepositingDestructor here
     ~C() { delete pData; }                               // Normal


Std-Discussion mailing list