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.
