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