Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++11 status.

1255.declval should be added to the library

Section: 22.2[utility]Status:C++11Submitter: Daniel KrüglerOpened: 2009-11-03Last modified: 2016-01-28

Priority:Not Prioritized

View all otherissues in [utility].

View all issues withC++11 status.

Discussion:

During the Santa Cruz meeting it was decided to split off the provisionof the library utilityvalue() proposed inN2979from the concrete request of theUK 300comment.The provision of a new library component that allows the production ofvalues in unevaluated expressions is considered as importantto realize constrained templates in C++0x where concepts are notavailable.

The following proposed resolution is an improvement over that suggested inN2958,because the proposed component can now be defined without loss ofgeneral usefulness and anyuse by user-code will make the program ill-formed.A possible prototype implementation that satisfies the core languagerequirements can be written as:

template<class T>  struct declval_protector {    static const bool stop = false;    static typename std::add_rvalue_reference<T>::type delegate();// undefined  };template<class T>typename std::add_rvalue_reference<T>::type declval() {  static_assert(declval_protector<T>::stop, "declval() must not be used!");  return declval_protector<T>::delegate();}

Further-on the earlier suggested namevalue() has been changed todeclval()after discussions with committee members.

Finally the suggestion shown below demonstrates that it can simplifyexisting standard wording by directly using it in the libraryspecification, and that it also improves an overlooked corner case forcommon_type by adding support forcv void.

[2009-11-19 Moved to Tentatively Ready after 6 positive votes on c++std-lib.]

Proposed resolution:

[The proposed resolution has been updated toN3000numbering and wording]

1. Change 22.2[utility], header<utility> synopsisas indicated:

   // 20.3.3, forward/move:template <class T> struct identity;template <class T, class U> T&& forward(U&&);template <class T> typename remove_reference<T>::type&& move(T&&);// 20.3.4, declval:template <class T> typename add_rvalue_reference<T>::type declval(); // as unevaluated operand

2. Immediately after the current section 22.2.4[forward] insert anew section:

   20.3.4 Function template declval [declval]

   The library provides the function templatedeclval to simplifythe definition of expressions which occur asunevaluated operands (7[expr]). Thetemplate parameterT ofdeclval maybe an incomplete type.

   template <class T> typename add_rvalue_reference<T>::type declval(); // as unevaluated operand

   Remarks: If this function is used according to 6.3[basic.def.odr],the program is ill-formed.

   [Example:

   template<class To, class From>decltype(static_cast<To>(declval<From>())) convert(From&&);

   declares a function templateconvert, which only participates inoverloading if the typeFrom can be explicitly cast to typeTo.For another example see class templatecommon_type(21.3.9.7[meta.trans.other]).—end example]

3. This bullet just makes clear that after applyingN2984, the changes in 21.3.6.4[meta.unary.prop], beforetable Type property queries shouldnot usedeclval,because the well-formedness requirement of the specification ofis_constructible would become more complicated, because wewould need to make sure that the expressionCE is checked in anunevaluated context.

4. Also 21.3.8[meta.rel]/4 is not modified similar to the previous bullet,because with the stricter requirements of not usingdeclval() the well-formedness conditionwould be harder to specify. The following changes are only editorial ones (e.g.the removal of the duplicate declaration ofcreate()):

   Given the following function prototype:

   template <class T>  typename add_rvalue_reference<T>::type create();

   the predicate condition for a template specializationis_convertible<From, To> shall be satisfied if and onlyif the return expression in the following code would be well-formed,including anyimplicit conversions to the return type of the function:

   template <class T>typename add_rvalue_reference<T>::type create();To test() {  return create<From>();}

5. Change the entry in column "Comments" forcommon_type in Table 51 —Other transformations (21.3.9.7[meta.trans.other]):

   [NB: This wording change extends the type domain ofcommon_type forcvvoid => cv void transformations and thus makescommon_type usable forall binary type combinations that are supported byis_convertible]

   The member typedeftype shall be defined as set out below. Alltypes in the parameter packT shall be completeor(possibly cv-qualified)void. A program may specializethis trait if at least one template parameter in the specialization is auser-defined type. [Note: Such specializations are needed whenonly explicit conversions are desired among the template arguments.—end note]

6. Change 21.3.9.7[meta.trans.other]/3 as indicated:

   [NB: This wording change is more than an editorial simplification ofthe definition ofcommon_type: It also extends its usefulness forcvvoid types as outlined above]

   The nested typedefcommon_type::type shall be defined as follows:

   [..]

   template <class T, class U>struct common_type<T, U> {private:  static T&& __t();  static U&& __u();public:  typedef decltype(true ?__tdeclval<T>() :__udeclval<U>()) type;};

7. Change 99 [func.ret]/1 as indicated[This part solves some main aspects of issue1225⁽ⁱ⁾]:

   namespace std {  template <class> class result_of; // undefined  template <class Fn, class... ArgTypes>  class result_of<Fn(ArgTypes...)> {  public :// types    typedefsee belowdecltype(declval<Fn>() ( declval<ArgTypes>()... )) type;  };}

   1 Given an rvaluefn of typeFn and valuest1, t2, ..., tN oftypesT1, T2, ..., TN inArgTypes,respectively, thetype member is the result type of the expressionfn(t1, t2, ...,tN). The valuestiare lvalues when the corresponding typeTi is an lvalue-referencetype, and rvalues otherwise.