OK, I can see that destructor syntax is superior for that case.

What about the issue of subobjects, though? Do those have their usual
destructors called or is there opportunity to override that? In any case,
in what order do destructors get called in - is it the usual order
(backwards) or in reverse (forwards)?

And what if you want to destructive move not into a region of storage but
into a prvalue? Constructor syntax makes that easy to implement; destructor
syntax would require considerable gymnastics from the compiler.


On Fri, Feb 12, 2021 at 7:56 PM Maciej Polanski via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> 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]> 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
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>