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.]
The Standard uses the terms “block scope” and “local scope” interchangeably, but the former is never formally defined. Would it be better to use only one term consistently? “Block scope” seems to be more frequently used.
Notes from the October, 2007 meeting:
The CWG expressed a preference for the term “local scope.”
Notes from the September, 2008 meeting:
Reevaluating the relative prevalence of the two terms (including the fact that new uses of “block scope” are being introduced, e.g., in both the lambda and thread-local wording) led to CWG reversing its previous preference for “local scope.” The resolution will need to add a definition of “block scope” and should change the title of 6.4.3 [basic.scope.block].
Proposed resolution (October, 2009):
Change 6.4.2 [basic.scope.pdecl] paragraph 2 as follows:
[Note: a
nonlocalname from an outer scope remains visible up to the point of declaration of thelocalname that hides it. [Example:const int i = 2; { int i[i]; }declares a
localblock-scope array of two integers. —end example] —end note]
Change the section heading of 6.4.3 [basic.scope.block] from “Local scope” to “Block scope.”
Change 6.4.3 [basic.scope.block] paragraph 1 as follows:
A name declared in a block (8.4 [stmt.block]) is local to that block; it has block scope. Its potential scope begins at its point of declaration (6.4.2 [basic.scope.pdecl]) and ends at the end of itsdeclarative regionblock. A variable declared at block scope is a local variable.
Change 6.4.3 [basic.scope.block] paragraph 3 as follows:
The namein a catch exception-declarationdeclared in an exception-declaration is local to thehandlerhandler and shall not be redeclared in the outermost block of thehandlerhandler.
Change _N4868_.6.4.10 [basic.scope.hiding] paragraph 3 as follows:
In a member function definition, the declaration of alocalname at block scope hides the declaration of a member of the class with the same name...
Change 6.6 [basic.link] paragraph 8 as follows:
...Moreover, except as noted, a name declaredin a localat block scope (6.4.3 [basic.scope.block]) has no linkage...
Change 6.9.3.3 [basic.start.dynamic] paragraph 1 as follows:
...For an object of array or class type, all subobjects of that object are destroyed before anylocalblock-scope object with static storage duration initialized during the construction of the subobjects is destroyed.
Change 6.9.3.3 [basic.start.dynamic] paragraph 2 as follows:
If a function contains alocalblock-scope object of static or thread storage duration that has been destroyed and the function is called during the destruction of an object with static or thread storage duration, the program has undefined behavior if the flow of control passes through the definition of the previously destroyedlocalblock-scope object. Likewise, the behavior is undefined if thefunction-localblock-scope object is used indirectly (i.e., through a pointer) after its destruction.
Change 6.9.3.3 [basic.start.dynamic] paragraph 3 as follows:
If the completion of the initialization of anon-localnon-block-scope object with static storage duration is sequenced before a call to std::atexit (see <cstdlib>, 17.5 [support.start.term]), the call to the function passed to std::atexit is sequenced before the call to the destructor for the object. If a call to std::atexit is sequenced before the completion of the initialization of anon-localnon-block-scope object with static storage duration, the call to the destructor...
[Editorial note: the occurrences of “non-local” in this change are removed by the proposed resolution for issue 946.]
Change 8.4 [stmt.block] paragraph 1 as follows:
...A compound statement defines alocalblock scope (6.4 [basic.scope])...
Change 8.5 [stmt.select] paragraph 1 as follows:
...The substatement in a selection-statement (each substatement, in the else form of the if statement) implicitly defines alocalblock scope (6.4 [basic.scope])...
Change 8.5 [stmt.select] paragraph 5 as follows:
If a condition can be syntactically resolved as either an expression or the declaration of alocalblock-scope name, it is interpreted as a declaration.
Change 8.6 [stmt.iter] paragraph 2 as follows:
The substatement in an iteration-statement implicitly defines alocalblock scope (6.4 [basic.scope]) which is entered and exited each time through the loop.
Change 8.8 [stmt.dcl] paragraph 3 as follows:
...A program that jumps84 from a point where alocalvariable with automatic storage duration...
Change 8.8 [stmt.dcl] paragraph 4 as follows:
The zero-initialization (9.4 [dcl.init]) of alllocalblock-scope objects with static storage duration (6.7.5.2 [basic.stc.static]) or thread storage duration (6.7.5.3 [basic.stc.thread]) is performed before any other initialization takes place. Constant initialization (6.9.3.2 [basic.start.static]) of alocalblock-scope entity with static storage duration, if applicable, is performed before its block is first entered. An implementation is permitted to perform early initialization of otherlocalblock-scope objects...
Change 8.8 [stmt.dcl] paragraph 5 as follows:
The destructor for alocalblock-scope object with static or thread storage duration will be executed if and only if the variable was constructed. [Note: 6.9.3.3 [basic.start.dynamic] describes the order in whichlocalblock-scope objects with static and thread storage duration are destroyed. —end note]
Change 9.5 [dcl.fct.def] paragraph 7 as follows:
In the function-body, a function-local predefined variable denotes alocalblock-scope object of static storage duration that is implicitly defined (see 6.4.3 [basic.scope.block]).
Change the example in 11.3 [class.name] paragraph 2 as follows:
... void g() { struct s; // hide global struct s // with alocalblock-scope declaration ...
Change the example in 11.3 [class.name] paragraph 3 as follows:
... void g(int s) { struct s* p = new struct s; // global s p->a = s; //localparameter s }