Am 10.11.2013 20:46, schrieb Walter Bright:
On 11/10/2013 6:52 AM, Benjamin Thaut wrote:
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.
You completely ignored my inlining argument. Lets assume there is some
small function that qualifies for inlining but accesses a TLS variable
marked with the export attribute. The compiler now wants to cross-module
inline it. How does it do that, if there is no way to access TLS
variables across DLL boundaries? The obvious solution would be, not do
it at all. That means to disqualify all functions that do TLS access for
cross-module inlining, because the compiler can't know if they are
linked in from a static or shared library.
With D beeing a language that aims for performance, do we really want to
do that?
Kind Regards
Benjamin Thaut
