First Draft: Symbol Representation (Export)

[Richard (Rikki) Andrew Cattermole]

On 30/03/2024 2:28 AM, Johan wrote:
> On Thursday, 29 February 2024 at 11:15:07 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> 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)
> 
> Quick remark:
> `export ( Identifier )`
> will have all the problems associated with version identifiers, in 
> particular that you cannot combine version identifiers (A && B) or 
> generate them briefly from boolean expressions. Is there a reason why 
> you do not allow boolean expression here?
> 
> -Johan

At the current point in time, I don't see any reason to introduce that 
behavior.

The version that would be provided should be coming from the compiler or 
your build manager.

If you are not limiting yourself to ``InBinary_*``, you're probably 
going to have a lot of pain.

It is meant for advanced situations where the external import path 
switch might be giving the wrong results and you need to go on a per 
symbol basis.