This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115e. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-11-11
[Voted into WP at March, 2010 meeting.]
According to 9.2.2 [dcl.stc] paragraph 4,
The thread_local specifier shall be applied only to the names of objects or references of namespace scope and to the names of objects or references of block scope that also specify static.
Why require two keywords, where one on its own becomes ill-formed? thread_local should imply static in this case, and the combination of keywords should be banned rather than required. This would also eliminate the one of two exceptions documented in paragraph 1.
Notes from the July, 2009 meeting:
The consensus of the CWG was that thread_local should imply static, as suggested, but that the combination should still be allowed (it is needed, for example, for thread-local static data members).
Proposed resolution (October, 2009):
Change 9.2.2 [dcl.stc] paragraph 4 as follows:
The thread_local specifier indicates that the named entity has thread storage duration (6.7.5.3 [basic.stc.thread]). It shall be applied only to the names of objects or references of namespacescope, to the names of objects or references ofor block scopethat also specify extern or static,and to the names of static data members.It specifies that the named object or reference has thread storage duration (6.7.5.3 [basic.stc.thread]).When thread_local is applied to a variable of block scope the storage-class-specifier static is implied if it does not appear explicitly.