DIP 45 - approval discussion

[Benjamin Thaut]

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