On Mon, Nov 11, 2024 at 7:09 AM Oliver Hunt via Ext <ext_at_[hidden]>
wrote:

>
>
> > On Nov 10, 2024, at 7:46 PM, Peter Dimov via Ext <ext_at_[hidden]>
> wrote:
> >
> >> https://isocpp.org/files/papers/P3493R0.html
> >
> > "There are suggestions that it's enough to access-control data, and
> leave metadata (types, names, cardinalities) fully-accessible.
> >
> > That suggestion also doesn't model how the language works. Access
> controls control metadata as well as data. You can't name the data members
> of PolarRep/VectorRep/C1/C2/C3/C4, you can't get their types, you can't
> count how many such members exist; you do not have access to the metadata
> any more than you have access to the data.
> >
> > And of course you don't."
> >
> > I have a few things to say about this.
> >
> > First, at present, "of course" you don't have access
> > to anything reflected. That's exactly what we're trying
> > to fix with 2996.
> >
> > Second, the principle here is that if I can physically see
> > in the source code that the class has private members of
> > types C1, C2, C3, then the program should also be able to
> > see that, using the reflection facilities. If not, we don't
> > really have reflection, and we'll have to use other means,
> > such as parsing the source with libclang, or parsing the
> > debug info, and so on. Basically, what we do today and
> > hope we wouldn't need to do tomorrow.
>
>
> 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.
>

There aren't that many (and I somewhat doubt automatic serialization will
be used that often as non-toy software cares about providing stable formats
that are often independent from in-memory representation).
But mostly, that is useful or cool ought to be a secondary concern to
making sure introducing reflection is not going to make non-toy C++
programs, especially in large teams, companies, and in projects with third
party dependencies maintainable over time.
The idea that the developer application ought to have full control and
power is alluring but we know it doesn't work in practice.

No library developer will want users to reflect on their non-public
interfaces. The standard needs to show discipline because users won't.


> 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).
>
> —Oliver
>
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2024/11/23799.php
>