Date: Mon, 11 Nov 2024 09:59:04 -0500
One of the design goals I frequently heard expressed for reflection is that we can pilot new language features using reflection, rather than asking less qualified developers to implement their own C++ compiler (OK, work within a large open source compiler that is a serious learning investment) — and potentially standardize that reflected feature rather than change the core language.
The current specification in P2900 was very helpful in that regard, letting me prototype several designs for the type traits proposed for P2786 (trivial relocation) and those relied on being able to query every data member of an arbitrary class, to determine if a property was present or denied by any of its members. This was to support a core language facility, so could not depend on types implementing some library protocol — access to the private data members and bases was essential.
The domain of reflection goes beyond the domain of application programming, and serves needs that would be in conflicting best practices for different domains. We must support both, but there may be good questions raised about which has priority as the default interface.
My experience, coming from my limited usage, was that “reflection supports language abstraction” will be my own primary use case, so access to private members is expected; never trust a data set with just a single data point!
AlisdairM
> On Nov 11, 2024, at 1:30 AM, Ville Voutilainen via Lib-Ext <lib-ext_at_[hidden]> wrote:
>
> 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.
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2024/11/28618.php
The current specification in P2900 was very helpful in that regard, letting me prototype several designs for the type traits proposed for P2786 (trivial relocation) and those relied on being able to query every data member of an arbitrary class, to determine if a property was present or denied by any of its members. This was to support a core language facility, so could not depend on types implementing some library protocol — access to the private data members and bases was essential.
The domain of reflection goes beyond the domain of application programming, and serves needs that would be in conflicting best practices for different domains. We must support both, but there may be good questions raised about which has priority as the default interface.
My experience, coming from my limited usage, was that “reflection supports language abstraction” will be my own primary use case, so access to private members is expected; never trust a data set with just a single data point!
AlisdairM
> On Nov 11, 2024, at 1:30 AM, Ville Voutilainen via Lib-Ext <lib-ext_at_[hidden]> wrote:
>
> 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.
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2024/11/28618.php
Received on 2024-11-11 14:59:18