[ 2017-06-02 Issues Telecon ]

Resolve as NAD; note that P0550 addresses this

[ 2017-02 in Kona, LEWG recommends NAD ]

Send a paper to reopen: we'll need to bikeshed names if we decide to pursue such a design. It'll need to discuss difference between this and decay, and make choices about array types, and discuss why references are removed but not pointers.

[ 2009-10 Santa Cruz: ]

NAD Future.

[ 2009-10-14 Daniel adds: ]

remove_all seems too generic, a possible alternative matching the current naming style could be remove_cv_reference or remove_reference_cv. It should also be considered whether this trait should also remove 'extents', or pointer 'decorations'. Especially if the latter situations are considered as well, it might be easier to chose the name not in terms of what it removes (which might be a lot), but in terms of it creates. In this case I could think of e.g. extract_value_type.

Sometimes it is necessary to remove all qualifiers from a type before passing on to a further API. A good example would be calling the tuple query APIs tuple_size or tuple_element with a deduced type inside a function template. If the deduced type is cv-qualified or a reference then the call will fail. The solution is to chain calls to remove_cv<remove_reference<T>::type>::type, and note that the order matters.

Suggest it would be helpful to add a new type trait, remove_all, that removes all top-level qualifiers from a type i.e. cv-qualification and any references. Define the term in such a way that if additional qualifiers are added to the language, then remove_all is defined as stripping those as well.