In the cases you're describing, the types in question */opt into/ *being
reflected for the purposes of editors or serialisation, do they not? In
this way reflection is offering you a way to automate the generation of
boilerplate */you could have written anyway/*, using regular access
respecting C++? Conversely, I assume you are not as interested in
*/generically/* reflecting the privates of */arbitrary/* types. Is that
correct? E.g. you're not interested in decomposing a std::vector into
members like _M_start, _M_finish, _M_end_of_storage in your editor? If
I've understood correctly, then these use cases you describe do not
require */unrestricted/* access to privates of */arbitrary/* types. They
only require the reflection machinery to be */given/* access to the
private members of any classes that do */opt in/*.

On 11/11/2024 11.12, Jeremy Ong via SG7 wrote:
> > The standard needs to show discipline because users won't.
>
> I've worked extensively with game engine technologies where we've
> explored reflection done in user space for well over a decade now.
> While I can't speak to all game engines, I've used several large
> commercial ones, and a couple large internal engines. For the most
> part reflection /must/ encompass public, private, and protected
> members, and failure to do so would break tooling and cause huge
> surprises to users when member field visibility changes. Reflection is
> typically built on custom preprocessors, and to a lesser extent,
> compiler-assisted tooling like clang. Reflection is used to surface
> editable properties to artists and content creators in tools,
> serialize payloads to disk, serialize networked properties over the
> network interface, and other such use cases. The visibility of a
> property/field or even member function to other C++ interfaces is an
> orthogonal concern to visibility in these other externally-facing use
> cases. I actually can't think of a single moment where I cared to
> iterate over specifically /public /fields of a class. If we needed to
> control visibility, this was typically done with user-defined
> attributes we'd attach to the properties themselves.
>
> In short, I don't think the desire or need to bypass the C++ access
> specifiers has anything to do with a lack of "discipline." They are
> not the same problem, and visibility in the C++ domain is not to be
> conflated with visibility in the exterior domain (which is what
> reflection is intended to tie us to). Here is a page that lists a
> number of property specifiers used in Unreal to annotate how fields
> are exposed to other bits of tooling:
> https://benui.ca/unreal/uproperty/. The official documentation is here
> (https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-uproperties#propertyspecifiers)
> but Ben's page is a bit more illustrative of the end effect.
>
> I understand that game engines are but one slice of the pie among a
> variety of C++ users in our community, but thought I'd weigh in
> briefly because I believe game developers likely have clocked more
> hours with reflection in general, with perhaps more intensive needs
> (not as a general rule, this is a personal observation, I'm sure there
> are exceptions).
>
> Best,
> Jeremy
>
> On Mon, Nov 11, 2024 at 1:56 AM Corentin via SG7
> <sg7_at_[hidden]> wrote:
>
>
>
> 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
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
>