https://issues.dlang.org/show_bug.cgi?id=15523
--- Comment #6 from Jacob Carlborg <[email protected]> --- (In reply to Manu from comment #4) > I would suggest that since 'thread_local' is C++11 standard, then that > should be the one. That would be a breaking change. > Since '__thread' is not standard, I imagine it would be best supported by > GDC(/Clang?) via the @attribute("__thread") mechanism that they support for > their compiler-specific attributes. thread_local is not supported by the version of Clang supplied by Apple. The one most likely installed. > extern(C++): > > // Standard: > extern int i; // thread_local > > // GCC(/Clang?): > @attribute("__thread") extern int i; // __thread (this is probably very easy > for those toolchains to implement) DMD need to be able to handle it as well. Perhaps through a pragma? This would only affect extern(C++)? Would it be confusing to need to specify @attribute("__thread") only when the linkage is C++? I found this stackoverflow thread explaning the different sematnics of __thread and thread_local [1]. It looks like if you use thread_local for any use case that __thread is valid, it will behave the same, except when it's declared "extern". [1] http://stackoverflow.com/questions/13106049/c11-gcc-4-8-thread-local-performance-penalty --
