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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion