Movatterモバイル変換

[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 adecltype-specifier or

• the right operand of a comma operator that is the operand ofadecltype-specifier,

a temporary object is not introduced for the prvalue. Thetype of the prvalue may be incomplete. [Note: as aresult, storage is not allocated for the prvalue and it isnot destroyed; thus, a class type is not instantiated as aresult of being the type of a function call in thiscontext. This is true regardless of whether the expressionuses function call notation or operator notation(12.2.2.3 [over.match.oper]). —end note][Note: unlike the rule foradecltype-specifier that considers whetheranid-expression is parenthesized(9.2.9.3 [dcl.type.simple]), parentheses have no specialmeaning 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 inwhich the return type is an abstract class should be a deductionfailure, per 13.10.3 [temp.deduct] paragraph 8, last bullet:

• ...

• Attempting to create a function type in which a parametertype 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 adecltype-specifier not be instantiated prevents the detectionof 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 alsoissue 1640.)