This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 1120. New type trait - `remove_all`

Section: 20.15 [meta] Status: NAD Submitter: Alisdair Meredith Opened: 2009-05-23 Last modified: 2020-09-06

Priority: Not Prioritized

View other active issues in [meta].

View all other issues in [meta].

View all issues with NAD status.

Discussion:

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.

[ 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`.

[ 2009-10 Santa Cruz: ]

> NAD Future.

[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.

[2017-06-02 Issues Telecon]

Resolve as NAD; note that P0550 addresses this

Proposed resolution: