On Mon, 11 Nov 2024 at 08:09, Oliver Hunt via Ext <ext_at_[hidden]> wrote:
> Entirely in agreement here - restricting access to private fields from being accessible via reflection based on source level annotations that exist to stop developers from misusing members and data that aren’t intended to be directly accessed outside of the class is good defensive practice. However limiting _reflection_ from examining those data is severely limiting to many basic uses of reflection, a canonical example is serialization, but there are numerous others.

Serialization, hashing, and other use cases are attainable by defining
an API for that use case and using generative programming techniques
to produce the necessary opt-ins for such an API, without breaking
through access controls.

> In the context of P2719, having the ability to (transitively) introspect all fields of a type is useful for the purpose of an allocator wanting to reason about the properties of a type. Precluding access to the actual content of a type drastically limits the use of reflection for this purpose (and forces developers to rely on compiler extensions, manual annotations, manual adoption, and or external tools like libclang, etc to provide the necessary information).

Perhaps we should have reflection queries for such properties, instead
of relying on access-bypassing reflection of privates.