This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-19
[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.)