On Thu, 22 Jun 2023, 02:01 Julian Waters via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Hi all, I've written up a draft for static and shared libraries in the C++
> Language, I'm hoping to get some feedback so I can improve it. I apologize
> if this is not the proper format, I didn't have much time to put this
> together and don't really know the proper tools for doing so, since this is
> my first time writing a C++ draft. All feedback welcome!
>
> Document number: *PnnnnR0*
> Date: *2023-mm-dd*
> Audience: Library Evolution Working Group
> Reply-to: Julian Waters <tanksherman27_at_[hidden]>
>
> I. Table of Contents
>
> II. Introduction
>
> Introduce official support and specification for compiling C++ code as
> static or shared libraries (distinct from executable programs) to the C++
> Language, and an additional linkage type of "imported" and "exported" to
> the existing linkages of none, internal, and external, for use within the
> aforementioned shared libraries.
>
> III. Motivation and Scope
>
> Libraries have been an unofficial and nonstandard, yet enormous part of
> C++ for a long time. Code in a vast amount of codebases and repositories
> rely on compiling and distributing libraries to be used and linked into
> executable programs. Operating System support for shared libraries in
> particular, is virtually ubiquitous. Code compiled as a shared library has
> its merits, including by not limited to:
>
> -Reduced amount of duplicated code in each binary
>
> -Runtime loading on the fly, allowing for plugin systems and hotswapping
> code quickly by changing a single library
>
> Despite the widespread adoption of such libraries by compiler vendors,
> operating systems, and users, they have not been officially specified. As
> such, many differing extensions to the C and C++ Languages have all come
> into play, each with different default behaviours and usages, making it
> difficult to write code that works on different platforms. However, it can
> be observed that the vast majority of them seem to operate based on one
> constant universal basis of symbols, internal to the library and external,
> meaning it is exported and can be called or accessed by an external
> process, giving room for well defined and standardized behaviour.
>
> The current proposal therefore is to provide a standard way of specifying
> exported linkages in shared libraries, as well as well defined linkage
> rules in static and shared libraries, while still leaving behaviour like
> name mangling implementation defined.
>
> IV. Impact On the Standard
>
> The current change proposed here is a new addition to the C++ Language, in
> particular to the issue of language linkage (more specifically, a new level
> of linkage in addition to the already existing linkages of none, internal,
> and external),
>
You seem to be muddling up the distinct topics of linkage and language
linkage here.



which is already part of the core language and syntax, and as such does not
> affect library components, nor do any library components depend on it
> (though it should be noted that library components from the standard
> library can formally be linked into executable programs or other shared
> libraries through the changes proposed here; this is already widely
> supported by compilers in nonstandard ways).
>
> Although most of the current proposal simply adds entirely new
> functionality to the C++ Language, there is a section within the "Phases of
> Compilation" section that will require minimal changes should this proposal
> be accepted.
>
> The current draft simply makes the common action of linking to shared
> libraries at runtime better defined, and provides a standard way to do so,
> in other words it is merely standardizing standard practices already
> supported by a vast amount of compilers through compiler specific
> extensions.
>
> V. Design Decisions
>
> Static libraries are treated as
>
What is a static library? You need to define what that means in the
standard.


implementation defined, to avoid the issue of over-specifying their
> behaviour, since too many restrictions can hurt the feasibility of
> inclusion into the standard. Majority of static libraries are essentially
> object files bundled together into a single large archive, so the same
> existing linkage rules following static, no linkage, and extern
> apply to them.
>
> Don't work in conjunction with modules: Such code extends outside of
> compilation units that modules work with, doing so would simply complicate
> the standardization.
>
> Introduce the exported language linkage, which is only valid within shared
> libraries.
>

What's a shared library? You need to define it.


Behaviourally equivalent to the extern "" language linkage, except that it
> specifies that the symbol it is applied to is exported from the shared
> library and can be used by other libraries and executable programs. Syntax:
> export "" <Declaration>.
>

What is the difference between a symbol in a shared library that is marked
that way and one that isn't? You need to introduce some kind of visibility
property, or define what it means to be exported from a shared library (and
how that differs from being exported from a module, and why you didn't
choose a different word).


Introduce the imported specifier, valid within programs and static or
> shared libraries. Functionally equivalent to the extern specifier, except
> that it is a compiler hint that the current symbol is not immediately found
> within any of the listed libraries
>
Listed where?


but rather is to be resolved at runtime. Is not strictly required, meaning
> code can also use the extern specifier in place of import; This is only
> meant as a compiler hint for optimizations.
>

What kind of optimisations does this permit?

Can be used together with extern such as import extern, since it is a
> compiler hint. Code that defines a symbol marked as imported in the same
> translation is ill-formed. It is allowed for different declarations of
> a symbol to be marked as imported and extern separately, but no other
> linkages other than extern are allowed for a symbol marked as imported.
> Syntax: import [extern] <Declaration> (Takes precedence over modules)
>
> VI. Technical Specifications
>
> basic.start.main
>
> A program shall contain a global function called main
>
> ->
>
> An executable program shall contain a global function called main
>
> lex.phases
>
> All external entity references are resolved. Library components are linked
> to satisfy external references to entities not defined in the current
> translation. All such translator output is collected into a program image
> which contains information needed for execution in its execution
> environment.
>
> ->
>
> All external entity references are resolved. Library components, and any
> specified static or shared libraries, are linked to satisfy external
> references to entities not defined in the current translation. All such
> translator output is either collected into a program image or a
> static/shared library which contains information needed for execution in
> its execution environment.
>
> VII. Acknowledgements
>
> VIII. References
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>