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