Date: Sun, 10 Nov 2024 22:09:29 -0800
> 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.
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
>
>> 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.
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
Received on 2024-11-11 06:09:51