This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 113d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-03-20


2029. Abstract class return type in decltype operand

Section: 7.6.1.3  [expr.call]     Status: dup     Submitter: Mike Miller     Date: 2014-10-27

According to 7.6.1.3 [expr.call] paragraph 11, when a function call is the operand of a decltype-specifier,

a temporary object is not introduced for the prvalue. The type of the prvalue may be incomplete. [Note: as a result, storage is not allocated for the prvalue and it is not destroyed; thus, a class type is not instantiated as a result of being the type of a function call in this context. This is true regardless of whether the expression uses function call notation or operator notation (12.2.2.3 [over.match.oper]). —end note] [Note: unlike the rule for a decltype-specifier that considers whether an id-expression is parenthesized (9.2.9.3 [dcl.type.simple]), parentheses have no special meaning in this context. —end note]

This relaxation of requirements on the return type of a function does not mention abstract classes, so presumably the following example is ill-formed:

   struct Abstract {
     virtual ~Abstract() = 0;
   };

   template<class T> T func();

   typedef decltype(func<Abstract>()) type;

However, there is implementation variance on the treatment of the last line.

Rationale (November, 2014):

This issue is a duplicate of issue 1646.