Lauri Vasama wrote:
> Finally, it should be understood that access breaking is not necessary for
> flagship reflection use cases such as serialization, because any such use case
> requires cooperation between the serializer and the class being serialized. This
> is because access controls imply invariants and given an arbitrary class, it is
> impossible to deduce those invariants through reflection. Most likely that
> cooperation will take the form of annotations provided by the serialization
> library. Given that cooperation is necessary, it is not an undue burden for such
> a class to also befriend some part of the serialization library, as libraries have
> done for decades (see e.g. boost::serialization::access).

That's not entirely true. First, some flagship reflection use cases such as
computing the (default) hash value or printing a debug representation of the
object don't require any cooperation at all. (These only need const splicing
by the way.)

Second, for the cases where an object's serialized representation is the
serialized representation of all its subobjects (be they private), a generic
(de-facto standard) annotation is enough to enable the default serialization,
without any requirement for cooperation.

That is, if we have something like [[=std::please_serialize_me]], any serialization
library will be able to serialize the object, without the object having to be aware
of the library's existence.