Attached you will find a e-mail conversation about the discussion of DIP 45. I moved the discussion here so everyone can contribute.

Hi,

DIP 45 is waiting for some offical approval / comment so it can be implemented. It would be great if one of you could look into the topic and give official approval or improvement suggestions as the DIP has been in limbo for quite some time now. I'm not willing to start working on it before there is official approval, because I made bad experiences with this in the past.

In my opinion the DIP is in a state where further discussion will not lead to any improvements. The DIP should be implemented to see which problems arrise during implementation to then discuss how to solve them.

I've also seen a couple of questions to the state of Windows DLL support and shared libraries on the newsgroup. A working export keyword is required to actually implement that support on windows.

The DIP: http://wiki.dlang.org/DIP45
The latest discussion on the NG: http://forum.dlang.org/post/kvhu2c$2ikq$1@digitalmars.com
Bug associated with the problem: http://d.puremagic.com/issues/show_bug.cgi?id=9816

Kind Regards
Benjamin Thaut

Am 03.11.2013 20:32, schrieb Andrei Alexandrescu:
> This looks good to me and solidly motivated and anchored in practical experience. I approve with the mention that I'm not an expert in the matters involved so for the most part I trust the authors with the details.
>
> Walter?
>
>
> Andrei

Am 05.11.2013 00:32, schrieb Martin Nowak:
> On 11/03/2013 08:32 PM, Andrei Alexandrescu wrote:
>> This looks good to me and solidly motivated and anchored in practical experience. I approve with the mention that I'm not an expert in the matters involved so for the most part I trust the authors with the details.
>>
>> Walter?
> I think most of the DIP is sane. We came up with some complications for Windows so that
> export can replace both __declspec(dllimport) and __declspec(dllexport). I'd like to hear
> what Walter thinks about this.
>
> Otherwise I agree with Benjamin that it's mainly an issue of implementation now.

Am 08.11.2013 20:32, schrieb Walter Bright:
> It looks pretty good, except I have serious reservations about the -lib switch proposed behavior:
>
> 1. It's too blunt. A user could conceivably want to export some symbols and not others. This is all or nothing.
>
> 2. It requires the compiler to rewrite the .obj files, even ones that dmd did not create. I would consider this very surprising behavior. The user will be "WTF the object files in the lib are different from on my disk! D sux!" -lib is a simple-minded creature that currently does exactly what one would expect it to.
>
> 3. I've never heard anyone complain about the issue of a DLL referencing another DLL and the combined list of exports being the concatenation of both. It can be annoying, but it would be a minor issue. If it really is one, we can write a separate simple tool that strips exports from object files.
>
> And:
>
> Exporting of TLS variables is a minor issue. Frankly, I think people who export global variables should be burned at the stake anyway, why should we make it even easier? :-) Anyhow, if the user really, really wants to get himself immolated and export a TLS variable, he can always manually write the thunk (it is, after all, trivial).
>
> (Perhaps we could take this one step further - export doesn't apply to global variables, either, unless they are extern(C)?)
>
> I do like the idea that this proposal enables better code performance on Linux - better than C!

Am 08.11.2013 20:32, schrieb Walter Bright:
> It looks pretty good, except I have serious reservations about the -lib switch proposed behavior:
I'm glad you like the proposal.

>
> 1. It's too blunt. A user could conceivably want to export some symbols and not others. This is all or nothing.
A user is already able to control which symbols are exported and which are not by using the "export" attribute. Talking about expectations, when you come from C/C++ you usually expect that static libraries do _not_ contain any dll-exported symbols. At least I have never seen a single C or C++ static library that does contain dll-exported symbols. The -lib switch just deactivates dll-exporting symbols. I would also be fine with adding a additional compiler switch "--disable-export" or something like that. But I would strongly prefer a solution where I don't have to run additional tools on the generted object files to get rid of dll-exported symbols I didn't want in the first place, because I was compiling my code for a static library.

>
> 2. It requires the compiler to rewrite the .obj files, even ones that dmd did not create. I would consider this very surprising behavior. The user will be "WTF the object files in the lib are different from on my disk! D sux!" -lib is a simple-minded creature that currently does exactly what one would expect it to.
I can agree with that. The consensus in the newsgroup dicussion was though, that this is better then adding another compiler switch for disabeling dll-exported symbols, because that compiler switch would need to be added manually, whereas the -lib solution would work "magically". So the -lib solution whas thought to have better usability.

>
> 3. I've never heard anyone complain about the issue of a DLL referencing another DLL and the combined list of exports being the concatenation of both. It can be annoying, but it would be a minor issue. If it really is one, we can write a separate simple tool that strips exports from object files.

I don't think you understood the issue correctly. The issue is that you don't want to have dll-exported symbols from a static library inside a DLL. Static libraries are usually expected to not have any dll-exported smybols at all. For example when creating a DLL and you link against phobos you will always have all symbols from phobos & druntime inside your DLL, if we follow your suggested behaviour. This not only will lead to linker errors if you use two dlls that both link against phobos statically. But it will also make debugging and inspecting dll-exports harder as the dll will always have tons of exports you have to filter out.

>
> And:
>
> Exporting of TLS variables is a minor issue. Frankly, I think people who export global variables should be burned at the stake anyway, why should we make it even easier? Anyhow, if the user really, really wants to get himself immolated and export a TLS variable, he can always manually write the thunk (it is, after all, trivial).
I don't agree with that. It should be possible to create shared libraries which use all the capbailites of the language. And not restirct them to a arbitrary subset. In D TLS is a special issue because so many variables end up in TLS automatically. I'm especially thinking about inlining of small methods across dll boundaries. Also a shared library should really work the same way as a static one. Requiering a different design for a static versus a shared library seems inconsistent to me.
>
> (Perhaps we could take this one step further - export doesn't apply to global variables, either, unless they are extern(C)?)
>
> I do like the idea that this proposal enables better code performance on Linux - better than C!
>
I fully agree here, although this basically happened by accident. I was really astonished when I learned how much mostly useless indirections are added when compiling with -fPIC. Windows Dlls seem to have the better solution here regarding performance.

We should really continue this discussion on the newsgroup. If this is ok with you, just copy the e-mail conversation to a new newsgroup thread, or send me a message and I will do so.

Kind Regards
Benjamin Thaut

Am 09.11.2013 20:26, schrieb Martin Nowak:
> On 11/09/2013 08:11 PM, code@benjamin-thaut.de wrote:
>>> 2. It requires the compiler to rewrite the .obj files, even ones >>> that dmd did not create. I would consider this very surprising
>>> behavior. The user will be "WTF the object files in the lib are
>>> different from on my disk! D sux!" -lib is a simple-minded creature
>>> that currently does exactly what one would expect it to.
>> I can agree with that. The consensus in the newsgroup dicussion was
>> though, that this is better then adding another compiler switch for
>> disabeling dll-exported symbols, because that compiler switch would
>> need to be added manually, whereas the -lib solution would work
>> "magically". So the -lib solution whas thought to have better
>> usability.
> IIRC the main problem we're trying to solve is the following.
> If a static library contains object files with exported symbols those
> will
> be reexported from an exe/dll that links against the static library.
> Linking a static library into a dll is rare enough to justify a
> separate tool,
> but the exe case is problematic.

On 11/10/2013 12:42 PM, Benjamin Thaut wrote:
> Am 08.11.2013 20:32, schrieb Walter Bright:
>  > It looks pretty good, except I have serious reservations about the
> -lib switch proposed behavior:
> I'm glad you like the proposal.
>
>  >
>  > 1. It's too blunt. A user could conceivably want to export some
> symbols and not others. This is all or nothing.
> A user is already able to control which symbols are exported and which
> are not by using the "export" attribute. ...

Using the export attribute on some member exports the entire module info. If I understand this right, the module info will contain information also about non-exported members of the module and therefore even non-exported members will be accessible from outside. Is this correct?

Am 10.11.2013 13:03, schrieb Timon Gehr:
> On 11/10/2013 12:42 PM, Benjamin Thaut wrote:
>> Am 08.11.2013 20:32, schrieb Walter Bright:
>>  > It looks pretty good, except I have serious reservations about the
>> -lib switch proposed behavior:
>> I'm glad you like the proposal.
>>
>>  >
>>  > 1. It's too blunt. A user could conceivably want to export some
>> symbols and not others. This is all or nothing.
>> A user is already able to control which symbols are exported and which
>> are not by using the "export" attribute. ...
>
> Using the export attribute on some member exports the entire module
> info. If I understand this right, the module info will contain
> information also about non-exported members of the module and therefore
> even non-exported members will be accessible from outside. Is this correct?

AFAIK the module info only contains information about the (shared) module constructors and destructors. And no, non exported symbols will not be acessible because the neccessary accessors are not generated for them (at least on windows).

Am 10.11.2013 13:03, schrieb Timon Gehr:
> Using the export attribute on some member exports the entire module
> info. If I understand this right, the module info will contain
> information also about non-exported members of the module and therefore
> even non-exported members will be accessible from outside. Is this correct?

Addition: It is necessary to export the module info. Because as soon as you import a module and use any part of it, the compiler will reference the module info.

On 11/10/2013 01:06 PM, Benjamin Thaut wrote:
> Am 10.11.2013 13:03, schrieb Timon Gehr:
>> On 11/10/2013 12:42 PM, Benjamin Thaut wrote:
>>> Am 08.11.2013 20:32, schrieb Walter Bright:
>>>  > It looks pretty good, except I have serious reservations about the
>>> -lib switch proposed behavior:
>>> I'm glad you like the proposal.
>>>
>>>  >
>>>  > 1. It's too blunt. A user could conceivably want to export some
>>> symbols and not others. This is all or nothing.
>>> A user is already able to control which symbols are exported and which
>>> are not by using the "export" attribute. ...
>>
>> Using the export attribute on some member exports the entire module
>> info. If I understand this right, the module info will contain
>> information also about non-exported members of the module and therefore
>> even non-exported members will be accessible from outside. Is this
>> correct?
>
> AFAIK the module info only contains information about the (shared)
> module constructors and destructors.  And no, non exported symbols will
> not be acessible because the neccessary accessors are not generated for
> them (at least on windows).

What about Object.factory?