DIP 45 - approval discussion

Walter Bright newshound2 at digitalmars.com
Sun Nov 10 11:46:37 PST 2013


On 11/10/2013 6:52 AM, Benjamin Thaut wrote:
> Am 08.11.2013 20:32, schrieb Walter Bright:
>  >
>  > 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).
>
> In my opinion it should be possible to add "export:" to the top of every source
> file and then compiler a dynamic library which exatcly behaves like a static
> library. If you don't want TLS variables in interfaces this should also be
> forbidden for interfaces of static libraries, because this isn't really any
> difference. This really should be consistent. Either TLS variabels are not
> allowed at all within library interfaces or they are allowed and supported always.

I understand the consistency argument, but I'll also argue that if one raises 
consistency as an overriding requirement, everything else suffers. Everything is 
a tradeoff.

It's long been recognized that using global variables to communicate between 
interfaces is a bad idea. And it isn't even supported for dlls, because the 
proposed solution to making them work is to wrap them with a function (much like 
D properties).

We'd be going out of our way to support a recognized bad paradigm. There is 
currently no existing D code that requires this. If we add it, then we'd be 
stuck with supporting it for backwards compatibility. If we don't add it, and it 
becomes some sort of crisis that it isn't supported, we can add it in later 
without breaking things.



More information about the Digitalmars-d mailing list