Hello all,
I've been digesting yesterday discussions, and here is what I can propose to move forward:
- types cannot be relocated if they don't have a copy constructor or a move constructor defined and accessible.
- we remove relocation references and the relocation constructor.
- we introduce a new "operator reloc(T&& rhs)" static member function in classes, which will act both as a constructor and a destructor (much like P0023 relocator). This function can be defaulted, implicitly declared and defined just like constructors. This would likely require new syntax bits, more on that later.
- we keep the reloc operator. Calling reloc on an object will "relocate" the instance and mark the end of scope of its name. How the object is "relocated" is left to compiler vendors. The language offers the following relocation methods:
- If the type is trivially relocatable (p1144), then using std::memcpy is authorized. If this method is used then the language enforces that the destructor of the relocated object is not called.
- If the type provides an accessible "operator reloc" method, then it can be used to perform the relocation. Again the language enforces that the destructor of the relocated object is not called.
- Simply use a regular move (std::move). The destructor of the moved instance is called normally (i.e. when it goes out of scope).
That is, the destructor is called immediately, since the reloc
operator ended the scope of the name. I think that's a good thing.