Problem with coupling shared object symbol visibility with protection

[Walter Bright via Digitalmars-d]

On 2/16/2015 1:40 AM, Benjamin Thaut wrote:
> On Monday, 16 February 2015 at 08:08:17 UTC, Walter Bright wrote:
>>
>> At this point I suggest simply making those private helper functions public
>> and export them. It gets your project moving without waiting for language
>> changes (and this is a breaking change).
>
> This is in fact not a breaking change because export is broken anyway. Due to
> bug 922 export can't be used in cross platform libraries. I haven't seen a
> single library on dub that uses export (most likely for exactly that reason).
> Also export on windows is broken as well, see Bug 9816.
>
> So making export an attribute would most likely not break anything because it
> already is broken and wouldn't work if you tried to use it.

 From https://issues.dlang.org/show_bug.cgi?id=9816:

----------
Here is a list of all things wrong with export:

32 & 64 bit issues:
1) Exporting a global variable leads to a linker error
2) Exporting thread local variables should be an error (at least it is in c++)
3) The module info should be exported as soon the module has any exported
symbols
4) __gshared members of a class are not exported
5) The TypeInfo Object of the TestClass is not exported
6) The TypeInfo Object of TestStruct is not exported
---------

None of these are addressed by making export an attribute.