A keyword that is context sensitive was indeed what I had in mind, the
context was specifically why I brought up the concept of a "library" (or
shared object like a DLL) alongside it, since it wouldn't make much
sense to, say "export void createVM();" in C++ code that is indeed going to
be compiled as an executable program for example :P (ignore the association
export has with C++ modules in this example, just pretend that it would do
what __declspec(dllexport) does on Visual C++)

I was not aware modules were able to do that, I'll have to catch up on the
newer C++ revisions and versions, which I have admittedly fallen behind a
little on. It's worrying that so many proposals for defining dynamic/shared
libraries in the link Jonathan sent ultimately never saw the light of day
again though :(

best regards,
Julian

On Mon, Apr 3, 2023 at 9:50 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> 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.
>