[Adopted at the June, 2018 meeting as part of paper P0929R2.]

According to 7.6.1.3 [expr.call] paragraph 11,

If a function call is a prvalue of object type:

• if the function call is either

• the operand of a decltype-specifier or

• the right operand of a comma operator that 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]

• otherwise, the type of the prvalue shall be complete.

Thus, an example like

  template <class T> struct A: T { };
  template <class T> A<T> f(T) { return A<T>(); };
  decltype(f(42)) *p;

is well-formed. However, a function template specialization in which the return type is an abstract class should be a deduction failure, per 13.10.3 [temp.deduct] paragraph 8, last bullet:

• ...

• Attempting to create a function type in which a parameter type or the return type is an abstract class type (11.7.4 [class.abstract]).

The requirement that the return type in a function call in a decltype-specifier not be instantiated prevents the detection of this deduction failure in an example like:

  template <class T> struct A { virtual void f() = 0; };
  template <class T> A<T> f(T) { return A<T>(); };
  decltype(f(42)) *p;

It is not clear how this should be resolved.

(See also issue 1640.)