On 10/11/2026 20.34, Peter Dimov via SG7 wrote:

> 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.)

Hashing is an interesting case. It's true that given a defaulted
comparison, hashing all members should be safe in all but the most
contrived examples. On the other hand, to my knowledge it's not possible
to detect that defaulted comparison in general in C++26, particularly
when it is a hidden friend.

Any non-trivial debug printing, despite only reading, is still unsafe
due to unknowable concurrent access and state of initialization in the
target object. In the best case you get nonsense debug output due to a
torn read, and in the worst an exploitable vulnerability. Given that
this is a debugging feature intended mainly for logging and the like, it
seems especially important for it not to introduce further safety
issues. From what I can tell, the only safe solution to this problem is
to define a debug dumping facility that never automatically follows
pointers (e.g. in string views, as sad as that is for the quality of the
debug output). Since past the first access break it is unsafe to print
anything other than the raw scalar subobjects, this problem could be
solved in the standard library without letting the user break through
access controls.

> 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.

C++26 does not include such an annotation though. Any third party
library that does provide one is free to also define a class for
redirecting access as usual:

friend std::here_you_go;

// In the reflection library:
std::here_you_go::splice_subobject<info>(object)