Rationale:

The point here is to able to write T& given T and ReferentType is precisely the concept that guarantees so, according to N2677 (Foundational concepts). Because of this, it seems preferable than an explicit check for cv void using SameType/remove_cv as it was suggested in Sophia. In particular, Daniel remarked that there may be types other than cv void which aren't referent types (int[], perhaps?).

Proposed resolution:

Change definition of identity in [forward], paragraph 2, to:

template <class T>  struct identity {
    typedef T type;

    requires ReferentType<T>
      const T& operator()(const T& x) const;
  };

...

  requires ReferentType<T>
    const T& operator()(const T& x) const;

[ 2009-10 Santa Cruz: ]

Mark as NAD EditorialResolved, fixed by 939.

[ 2009-07-30 Daniel reopens: ]

This issue became closed, because the ReferentType requirement fixed the problem - this is no longer the case. In retrospective it seems to be that the root of current issues around std::identity (823, 700, 939) is that it was standardized as something very different (an unconditional type mapper) than traditional usage indicated (a function object that should derive from std::unary_function), as the SGI definition does. This issue could be solved, if std::identity is removed (one proposal of 939), but until this has been decided, this issue should remain open. An alternative for removing it, would be, to do the following:

1. Let identity stay as a real function object, which would now properly derive from unary_function:

   template <class T> struct identity : unary_function<T, T> {
     const T& operator()(const T&) const;
   };
   

2. Invent (if needed) a generic type wrapper (corresponding to concept IdentityOf), e.g. identity_of, and move it's prototype description back to [forward]:

   template <class T> struct identity_of {
     typedef T type;
   };
   

   and adapt the std::forward signature to use identity_of instead of identity.

[ Sophia Antipolis: ]

Jens: suggests to add a requires clause to avoid specializing on void.

Alisdair: also consider cv-qualified void.

Alberto provided proposed wording.

N2588 seems to have added an operator() member function to the identity<> helper in [forward]. I believe this change makes it no longer possible to instantiate identity<void>, as it would require forming a reference-to-void type as this operator()'s parameter type.

Suggested resolution: Specialize identity<void> so as not to require the member function's presence.