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.