In a normal PIMPL structure, the visible class is responsible for instantiating the private implementation class when the visible class is instantiated.  However, when serialization is restoring objects, it thinks it is responsible for instantiating all classes, including the private implementation classes of a PIMPL structure.  Who wins?  Do I end up with two instances of the private implementation class, one of which is just hanging in mid-air?

If you need a more solid background, here is what I'm doing:

Visible class header:
struct Foo_Private;
class Foo {
public:
    Foo();
    . . . other stuff . . .

    . . . data member-free serialization code . . .
private:
    const std::unique_ptr< Foo_Private() > d_ptr;
};

Visible class code:
Foo::Foo() : d_ptr(std::make_unique< Foo_Private >())
    {...code to initialize Foo_Private data members...}

Private Implementation class header:
struct Foo_Private {
    Foo_Private();
    . . . data member declarations . . .

    . . . data member serialization code . . .
};

Private implementation class has no code file.  It is a header-only class.

One alternative I thought of was to not serialize the private implementation class, even though it contains all of the data member that need serializing.  Instead, if the private class has data members, say, bar and baz, then the visible class would have a serialize() function that "reached into" the private object using its d_ptr:

template<class Archive>
void serialize(Archive & ar, const unsigned int version) {
    ar & d_ptr->bar;
    ar & d_ptr->baz;
}

So, the visible class (which has no data members of its own) is serialized using data extracted from/inserted into the private class object.

Would serialization-by-proxy work?