[Moved to DR at the February, 2014 meeting.]

Proposed resolution (November, 2013):

1. Change 6.1 [basic.pre] paragraph 6 as follows:

A variable is introduced by the declaration of a reference other than a non-static data member or of an object. The variable's name, if any, denotes the reference or object.

2. Change 6.7.7 [class.temporary] paragraph 1 as follows:

Temporaries of class type are created in various contexts: binding a reference to a prvalue (9.4.4 [dcl.init.ref]), returning a prvalue (8.7.4 [stmt.return]), a conversion that creates a prvalue (7.3.2 [conv.lval], 7.6.1.9 [expr.static.cast], 7.6.1.11 [expr.const.cast], 7.6.3 [expr.cast]), throwing an exception (14.2 [except.throw]), entering a handler (14.4 [except.handle]), and in some initializations (9.4 [dcl.init]). [Note:...

3. Change 14.2 [except.throw] paragraph 3 as follows:

Throwing an exception copy-initializes (9.4 [dcl.init], 11.4.5.3 [class.copy.ctor]) a temporary object, called the exception object. The temporary is an lvalue and is used to initialize the variable named declared in the matching handler (14.4 [except.handle]). If the type...

4. Change 14.4 [except.handle] paragraph 16 as follows:

If the exception-declaration specifies a name, it declares a variable which is copy-initialized (9.4 [dcl.init]) from the exception object. If the exception-declaration denotes an object type but does not specify a name, a temporary (6.7.7 [class.temporary]) is copy-initialized (9.4 [dcl.init]) from the exception object. The variable declared by the exception-declaration, of type cv T or cv T&, is initialized from the exception object, of type E, as follows:

• if T is a base class of E, the variable is copy-initialized (9.4 [dcl.init]) from the corresponding base class subobject of the exception object;

• otherwise, the variable is copy-initialized (9.4 [dcl.init]) from the exception object.

The lifetime of the variable or temporary ends when the handler exits, after the destruction of any automatic objects initialized within the handler.

Additional note (October, 2013):

Additional discussion has pointed out that, although the unnamed handler parameter is no longer called a “temporary” in the proposed resolution, 6.7.7 [class.temporary] paragraph 1 still lists “entering a handler (14.4 [except.handle])” as one of the contexts in which a temporary is created. A question was also raised as to whether it is necessary to deal with named and unnamed handler parameters separately, since both are now referred to as “variables” in the revised wording. This issue has therefore been returned to "review" status to allow consideration of these points.

Proposed resolution (September, 2013) [superseded]:

Change 14.4 [except.handle] paragraph 16 as follows:

If the exception-declaration specifies introduces a name, it declares a variable which is copy-initialized (9.4 [dcl.init]) from the exception object. If the exception-declaration denotes an object type but does not specify a name, a temporary (6.7.7 [class.temporary]) is copy-initialized (9.4 [dcl.init]) from the exception object.; otherwise, an unnamed variable is created. That variable, of type cv T or cv T&, is initialized from the exception object, of type E, as follows:

• if T is a base class of E, the variable is copy-initialized from the corresponding base class subobject of the exception object;

• otherwise, the variable is copy-initialized from the exception object.

The lifetime of the variable or temporary ends when the handler exits, after the destruction of any automatic objects initialized within the handler.

In saying that the catch-clause parameter is copy-initialized from the exception object, 14.4 [except.handle] paragraph 16 leaves open the possibility that a converting constructor might be used for the initialization when the type of the exception-declaration is a base of the type of the exception object. It should be specified that the parameter is copy-constructed from the corresponding base class subobject in such cases.