First Draft: Symbol Representation (Export)

Richard Andrew Cattermole (Rikki) richard at cattermole.co.nz
Thu Feb 29 11:15:07 UTC 2024


D's support for shared libraries has historically presented 
challenges for users, especially when dealing with complex use 
cases. This proposal aims to improve the user experience by 
establishing a user story that will provide a consistent and 
user-friendly approach to usage and compilation of binaries 
without a thorough understanding of linkers.

With the recent resolution of dmd's exportation support on 
Windows (druntime support is still under development), we are now 
ready to focus on making D's shared library capabilities more 
accessible and usable for common use cases.

Links: 
[current](https://gist.githubusercontent.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e/11e36e8a332324c5323792da2835337d0306a6c9) [latest](https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e)

Some features of this proposal:

- The ``export`` attribute is no longer a visibility modifier
- A new switch is added ``-extI``, the external import path switch
- Templates are not exported by default (prevents template 
emission bugs like 
[23255](https://issues.dlang.org/show_bug.cgi?id=23255) by 
requiring all templates in modules out of binary to instantiate)
- The D interface generator will be able to produce .di files 
that are suitable for usage with both static libraries and shared 
libraries.
- Gives a name to using export versus the visibility override 
switch as positive and negative notation
- Officialize the ``Have_`` prefix used in dub and introduce 
``InBinary_`` and ``Compiling_`` to enable very fined grained 
control over symbol mode as part of ``export``
- Generated symbols will be exported for a given encapsulation 
unit that has exportation

There has already been quite a bit of back and forth between me 
and Walter with the aid of Adam Wilson (Thanks!), for this reason 
this proposal is skipping the idea step.

In a previous version of this proposal a focus upon anything that 
affects shared libraries was taken. In this version of the 
proposal a focus upon things required for common use cases is 
taken, and when these are not taken direct failure to implement 
the use case in D occurs.



More information about the dip.development mailing list