DIP 45 - approval discussion

[Rainer Schuetze]

On 10.11.2013 12:38, Benjamin Thaut wrote:
> 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

I think the DIP is very reasonable. Some random comments:

- when building a single object file or library, I would expect that it 
won't be torn apart later, so optimizations currently limited to 
accesses within the same module by the DIP could be extended to the 
modules included in current compilation target.

- a better example where cross-DLL data accesses to globals are needed 
is TypeInfo, e.g. when a class info references it's base class or 
interfaces.

- I'd be fine with reversing the default for stripping exports from a 
library, i.e. replacing "-libexports" with "-stripexports".

- I agree that cross DLL TLS accesses should be possible, though it 
might be implemented in a second step. Last time I tried it with C++, it 
wasn't supported, but it is probably not missed that much as thread 
local data is not as ubiquitous as in D.

- The DIP should state what happens to template instances. Assuming the 
definition is marked "export", I guess instances will be dllexport if 
they are compiled together with the module that contains the definition. 
What will happen if it is instantiated, but the defining module is 
merely imported?

Rainer