On Mon, Sep 26, 2022 at 7:36 PM Edward Catmur <ecatmur@googlemail.com> wrote:
On Mon, 26 Sept 2022 at 15:20, Sébastien Bini <sebastien.bini@gmail.com> wrote:
I agree with the class invariant part.
But the no user-provided reloc, move and copy ctor clause was not motivated because of the invariant, but because we wanted to be sure that subobjects of a class could be independently relocated or destroyed. So at minimum we must have a default destructor. And that's not enough.

struct PainterGuard
{
    Painter* _p;
    StateGuard(Painter& p) : _p{&p} { _p->save(); }
    ~StateGuard() {  _p->restore(); }
};

class PainterWithGuard
{
public:
    PainterWithGuard(Painter p) : _p{reloc p}, _guard{_p} {}
    PainterWithGuard() : _guard{_p} {}
    PainterWithGuard(PainterWithGuard) /* reloc ctor */ { _guard._p = &_p; }
public:
    Painter _p;
private:
    PainterGuard _guard;
};

This is a perfectly valid class. Its default destructor works fine. Unfortunately, from outside the class (with no access to private data-members), doing:
`auto [p] = std::decompose<&PainterWithGuard::_p>(reloc painterWithGuard);`
Will call `restore()` on a destructed/relocated object.

Likewise doing (in the class implementation this time):
`auto [p, g] = std::decompose<&PainterWithGuard::_p, &PainterWithGuard::_guard>(reloc painterWithGuard);`
Will construct a PainterGuard that points to invalid data. This one can be incriminated to the class writer as it needs access to private data.

I agree this class has a bad design, but its safe to use otherwise. std::decompose shouldn't cause crashes on badly designed classes.

IMO the no user-provided reloc, move and copy ctor clause gives us that extra guarantee, that there are no relationships between subobjects and as such it is safe to independently relocate or destroy them.

Great example, and that's the sort of thing I was trying to describe with my talk of private inheritance. (PainterGuard could be a private base of PainterWithGuard, perhaps.)

But I can still write a similar class that is currently safe, has no user-defined special member functions but would be unsafe to decompose: instead of writing or deleting the relocating constructor, have PainterGuard inherit from boost::noncopyable.  So the existence of user-defined special member functions is insufficient to determine whether a class is safe to decompose.

Yes. But this example could also be viewed as to give us a hint that there must be no user-provided default constructor as well.
 
Instead, consider: `std::decompose` is accessing (on behalf of its caller) each direct subobject (base and data member) that is returned. But it is also accessing the *other* direct subobjects that it does not return, in order to destroy them.  So let's say that to call std::decompose, you must have access to each direct subobject, including those that you don't request. (Plus their relocators or destructors, respectively.)

Then `auto [p] = std::decompose<&PainterWithGuard::_p>(reloc painterWithGuard);` would be ill-formed because in that context, `painterWithGuard._guard` is ill-formed.

Do you think this would work?

But if _guard were declared as public by mistake then all those safeties are bypassed and std::decompose will cause trouble.
This also limits the use of std::decompose to the class implementation and friends. It is not necessarily a bad thing as it requires the owner to know of the class internals (or at least to be in the position of knowing...). Besides I expect the main use of std::decompose to be from the new special get_bindings function.

In addition, now that I think of it, the no user-provided special ctors and dtor clause is required to allow structure binding relocation from a class-type. In auto [x, y] = reloc data, data must be a C array (no problem there), a class-type with all data-members coming from the class-type or the same base, or provide a get_binding function that applies recursively. The end result of get_binding must fall into the C array case or the class-type case. For the class-type case, we must be allowed to split the type into individual subobjects, and have again that sort of guarantee that subobjects can be considered individually. Hence this no user-provided special ctors and dtor clause must apply to the class-type. This is the case for whatever std::decompose returns, but it is worth mentioning. And that bit makes me think that this clause should also apply to std::decompose.

I can't feel satisfied with this solution. We end up with two ways of decomposing: std::decompose and the get_binding function. get_binding is still necessary as you can't access nested subobjects from std::decompose, or even generate objects on demand when using structured bindings. And other times get_bindings can be bypassed if the user performs structured binding by calling std::decompose directly. I find this dual approach a bit confusing.