Hi,

Why do you propose to introduce this new special member function
'operator reloc'?
Can't we base relocation on move+destroy only? (or just memcpy + end
of scope in case of trivially relocatable types).

I.e.:
Obj a;
auto b = reloc a;

At 'reloc a' line, we either:
 1) construct 'b' by invoking move constructor from 'a', invoke
destructor for 'a', remove 'a' from scope
 2) construct 'b' by memcpy-ing 'a', do not invoke 'a' destructor,
remove ab' from scope

Regards,
Maciej

pon., 30 maj 2022 o 13:38 Sébastien Bini via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Hello all,
>
> Sorry for the late reply. I'll try to respond thoroughly.
>
> > POD is a deprecated term; presumably you mean trivial? It is not observable if a trivial class is relocated by move+destroy, so there is no ABI break for these.
>
> Yes, trivial. And agreed.
>
> About the ABI break:
>
> To summarize what has been said:
> - Non-trivial types need to opt-in to relocation by providing their own operator reloc(). If I understand correctly, this would involve an ABI change on functions where such types are passed by value, so that function parameters can be relocated (or more precisely, their destructor call can be alleviated).
> - Types can also opt-out of the ABI break by adding a potentially non-standardized attribute on their class definition. In which cases such function parameters can only be relocated by move constructor, the destructor being called at the caller site.
> - The proposal can then force STL types (for those where it makes sense) to implement their own operator reloc(), while library vendors are free to opt-out of the ABI break.
> - And yet we provide full support for relocatable-only types, even if they have STL types as data members.
>
> I am not an expert on ABI preservation, but that seems like a nice way to go.
>
> About the synthesized relocation:
>
> > Yes, that's exactly what I'm suggesting. Composition is necessary - here this means being able to combine a relocate-only and a move-destroy type as data members of a class, and have that aggregate remain usable.
> >
> > What problems do you foresee?
>
> I like that users don't have to explicitly call the destructor on the moved part, should they mean to write the initializer explicitly. But I feel mixed about this.
>
> Let's consider the following scenario:
>
> struct DB
> {
> DB(DB&&) = default;
> void start();
> void end();
> };
>
> struct Transaction
> {
> Transaction(Transaction&&) = default;
> explicit Transaction(DB& db); // calls DB::start
> ~Transaction() noexcept; // calls DB::end unless *this is in moved-from state
> };
>
> struct T
> {
> DB _db;
> Transaction _trans;
>
> operator reloc(T&& src) = default;
> };
>
> DB and Transaction are not relocatable as their operator reloc() is implicitly deleted. As such T's operator reloc will use synthesized relocation (move+destroy) from DB and Transaction. But it is important that, in operator reloc(), members are constructed in the order they are declared, and source members destructed in that reversed order.
>
> This means that operator reloc() will:
>
> Initialize each base class and data member in declaration order (_db and then _trans).
> Initialization is done either with trivial relocation, operator reloc(), move constructor, or is user-provided.
> Right after the initialization is done, and just before the operator reloc() function body is entered, the necessary destructors are called. The destructor of all base classes and data-members that got initialized by move or user code is called on the source object in the reversed declaration order (src._trans and then src._db).
>
> Now we pray that src._trans destructor will have no side effect on src._db (normally it shouldn't as it knows it has been moved-from). But we are walking on thin ice here. If DB had an operator reloc(), then src._db would be considered destructed before src._trans destructor is called (which is unusual in C++). If it had any effect on src._db, then it would end up modifying a destructed object.
>
> About the exception safety:
>
> I admit there are no strong arguments against proper exception handling. Here is what I can come up with:
>
> Operator reloc() acts in three stages: (a) the base classes and data members initialisation, (b) destruction in reversed declaration order on any subobject of the source object that did not get true relocation (synthesized relocation or user provided initialization), (c) the function body.
>
> If an exception leaks through in stage (a) then:
>
> in reversed declaration order, call the destructor of all initialized subobjects.
> in reversed declaration order, call the destructor of the following source subobjects:
>
> all subobjects that did not get relocated yet
> the subobjects that would get destructed in stage (b)
> if the initialization that threw did not happen through true relocation, then the matching subobject. (If the initialization happened by operator reloc() then we know that the source subobject is considered destructed.)
>
> We call the destructor on the new instance subobjects first as they were constructed more recently.
> If any extra exception leaks through during those destructor calls, then std::terminate is called (as it is done through stack-unwinding).
>
> If an exception leaks through in stage (b) then:
>
> All subobjects of the new instance are destructed in reversed declaration order.
> All the remaining destructors of the source subobject are called in the same order.
> If any extra exception leaks through during those destructor calls, then std::terminate is called (as it is done through stack-unwinding).
>
> If an exception leaks through in stage (c) then:
>
> All subobjects of the new instance are destructed in reversed declaration order.
> If any extra exception leaks through during those destructor calls, then std::terminate is called (as it is done through stack-unwinding).
>
> Last, delegating constructors with operator reloc() should also be allowed: `operator reloc(T&& src) : T{std::move(src)} {}`.
>
> In that case `src` is destructed right before the function body is entered.
> If an exception leaks through the delegating constructor, then `src` destructor is called normally and the exception is propagated:
>
> The new instance does not need to be destructed as the delegating constructor already took care of that.
> If an extra exception leaks through the destructor of `src` then std::terminate is called.
>
> All this looks nice, but I can't help to think of what would happen when a destructor is called on an unmoved subobject of the source that has a side-effect on an already relocated subobject. (see below)
>
> Exceptions and synthesized relocation:
>
> What happens now if someone adds an "operator reloc() = default;" to DB (or worse, if this is done automatically should DB be trivial)? Let's rewrite T:
>
> struct Throw
> {
> operator reloc(Throw&&) { throw std::runtime_error{"oops"}; }
> };
>
> struct T
> {
> DB _db;
> Throw _thrower;
> Transaction _trans;
>
> operator reloc(T&& src) = default;
> };
>
> In T's operator reloc():
>
> _db is initialized using its own operator reloc(). src._db is then considered destructed.
> _thrower will thow. Using the rules described above, operator reloc() needs then to destruct this->_db and then src._trans, before propagating the exception.
> this->_db.~DB() is called without any issue.
> src._trans.~Transaction() is called while src._trans is not in its moved-from state, so it will act on an object that theoretically reached its end of life (call src._db.end() while src._db is destructed). Ouch.
>
> This is even more painful when we know that T default move constructor does the right thing: when the exception is thrown, this->_db is destructed. src continues to live as normal, even though src._db is in a moved-from state. Given that DB can handle a call to DB::end() in a moved-from state, no problem will arise.
>
> We could argue that T should not be relocatable and that it's all bad user code. But still I wonder how much synthesized relocation and exceptions may break things...
>
> On the other hand, we could state that synthesized relocation does not happen, i.e. defaulting operator reloc() does not fallback on move+destruct on unrelocatable subobjects. operator reloc() would then be implicitly deleted if any base class or data-member has a (potentially implicitly) deleted operator reloc().
>
> Then users will be forced to write their own operator reloc() which has at least the benefit of questioning them on whether their class should be relocatable to begin with, and if yes, how to do it properly.
>
> Best regards,
> Sébastien
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals