On Mon, 3 Apr 2023 at 16:18, Julian Waters <tanksherman27_at_[hidden]> wrote:
>
> Hi,
>
> Sorry for the misconception, I am aware that libraries are not executable programs on their own, I should have worded that better.
>
> The reason is simple really: Libraries having a mechanism to specify what they export would be rather useful when writing them in C or C++ code. Currently there is no mechanism or definition about libraries when it comes to C and C++ however, nor anything to control what they export at runtime to a program that needs them when loaded (because obviously not everything in them is visible to whatever loaded them), which then means compiler extensions are required to do this instead, which becomes an extremely messy collection of macros when it comes to crossplatform code (think of the clashes between __declspec(dllexport) and __attribute__ visibility and so on). Although the linking model across these platforms differ substantially, one thing they do carry in common is that there are 2 types of visibilities: private, or only available inside the library, and public, meaning that function or data chunk is exported and placed into a symbol table of the library artifact/whatever. Since this is one thing that remains similar across pretty much every platform, I was wondering if formal unified syntax could be introduced for this purpose, making it easier to control what symbols are exported when writing cross-platform libraries in C++ (and C)

Thanks! That clarification makes things much clearer. Two comments:

1) Modules _do_ allow control of what is and is not exported.

2) In case you still want to add more control than that for modular
code, it should come with a rationale for why
not just use modules built as libraries. But if we want to continue
with that, then yeah, either a cross-platform attribute
or even a context-sensitive keyword would be the thing to strive for,
not fiddling with the wording you suggested to
modify.