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.
remove_allSection: 21 [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_allseems too generic, a possible alternative matching the current naming style could beremove_cv_referenceorremove_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: