DIP 45 - approval discussion

[Benjamin Thaut]

Am 11.11.2013 05:17, schrieb Walter Bright:
> On 11/10/2013 1:50 PM, Benjamin Thaut wrote:
>
> The compiler would benefit from knowing which modules are from a shared
> library, and it needs to anyway in order to distinguish between
> dllimport and dllexport.
>

Then you didn't understand the DIP correctly. One of the main points of 
this DIP is to provide a implementation of the export attribute that 
does _not_ require the compiler to know anything about, wether certain 
modules will end up in a DLL or not. With the proposed behaviour you 
could compile a module into an object file and then link it both into a 
DLL and static lirary. Both would just work. When using a library the 
compiler also doesn't have to know if the lirary is shared or static. 
Both will work and it will be decided at link time which path is coosen 
(static or shared). Generally this behaviour makes the export attribute 
easier to use and less error prone.

In an early version of this DIP did involve giving the compiler the 
information which modules end up in an shared library, but it was 
rejected in the discussion. A solution which does not require this 
information was preferred by almost all users taking part in the discussion.

>
> The trouble is, the proposed solution for exporting TLS variables is to
> wrap the access in a function that is not inline-able anyway. For
> performance oriented code, the user would be better off to write his own
> wrapper, and then hoist the call out of the hot spot, and use a pointer
> to the TLS variable in the hot spot.
>
> As a general rule, if code has a "hot spot" that crosses a DLL boundary,
> there is going to be performance problems with it regardless. I don't
> think this is a problem that the language can solve without some effort
> from the user.

Correct. But the compiler would still be able do other optimizations 
given the function is sligtly bigger then a simple getter.