Block-scope thread_local variables should be implicitly static
9.2.2 [dcl.stc]

Created on 2009-03-03.00:00:00 last changed 144 months ago


Date: 2010-03-15.00:00:00

[Voted into WP at March, 2010 meeting.]

Date: 2009-10-15.00:00:00

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 ( [basic.stc.thread]). It shall be applied only to the names of objects or references of namespace scope, to the names of objects or references of or block scope that 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 ( [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.
Date: 2009-07-15.00:00:00

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).

Date: 2009-03-03.00:00:00
N2800 comment UKĀ 87

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.

Date User Action Args
2010-03-29 00:00:00adminsetmessages: + msg2682
2010-03-29 00:00:00adminsetstatus: ready -> cd2
2009-11-08 00:00:00adminsetmessages: + msg2346
2009-11-08 00:00:00adminsetstatus: drafting -> ready
2009-08-03 00:00:00adminsetmessages: + msg2192
2009-08-03 00:00:00adminsetstatus: open -> drafting
2009-03-03 00:00:00admincreate