>
> I think it would be interesting to know from implementers if someone
> ever asked for such features.


I mean, I would like such a feature. One of the use cases I have in mind
for a feature like this (and why I'm following this discussion) is I would
like to write a runtime reflection library. I work in game development
where runtime reflection is _extremely_ useful for serialization, editing
of objects by non-programmers, scripting, network replication, and way
more. The codebase I work with, Unreal Engine, has a whole plugin system
using dynamically linked libraries that has a code generation utility that
generates runtime reflection code, and a set of functions that allow these
dynamically linked plugins to provide their reflection information to the
host program. This is all generated code and handled for you if you call
the unreal engine wrapper for loading dynamically linked libraries, so most
users don't even think about it and it just works.

If I wanted to make a fully standard and portable runtime reflection
library with p2996 reflection (and it's family of papers), I would need
both global arrays to store that reflection data, and a way to import
reflection data created by my library from dynamic libraries to support
those.



On Sat, Oct 19, 2024 at 1:25 PM Federico Kircheis via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On 19/10/2024 22.16, Garrett Fleenor via Std-Discussion wrote:
> > Hi folks, long time reader, first time commenter here
> >
> > I wonder if the solution to the dynamic linking issue is to specify some
> > "implementation defined (read: dllexport)" functions with specific names
> > to query what global arrays dynamic library contains, and specify some
> > functions that allow the programmer to manually link these global
> > containers together when the dynamic library is loaded through whatever
> > platform api is used. The objects and arrays themselves could be
> > immutable, but some range-like accessor API could be mutable to allow
> > linking global object stores together. Users would have to figure out
> > how to de-duplicate things themselves, but I think reflection/generation
> > would give us tools to generate some kind of comparable handle if that
> > was something a user's codebase needs.
> >
> > This would require users to handle linking the arrays together in a
> > dynamic linking situation and to handle the duplication issues, but I
> > don't see any elegant way to specify dynamic linking without actually
> > specifying how dynamic linking works... a massive can of worms that
> > would kill this extremely useful proposal/idea.
>
>
> I think it would be interesting to know from implementers if someone
> ever asked for such features.
>
> We know that the current implementation is used in the wild.
>
> If no one ever asked those features, it might be that we are trying to
> solve a problem not worth solving.
>
> I did not give it too much though, but every library interested in doing
> so could export the array/span/whatever through a function and let the
> application manually merge those arrays together.
> Not the best solution, but it would work with lazy loading too (dlopen),
> and it is somethng that it can already be done today.
> It would be an argument for not dismissing the years of experience we
> have with the current approach.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>