This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.
Section: 20.13.4 [allocator.adaptor.members] Status: WP Submitter: Tim Song Opened: 2018-06-04 Last modified: 2019-01-01
View all other issues in [allocator.adaptor.members].
View all issues with WP status.
OUTERMOST_ALLOC_TRAITS(x) is currently defined in 20.13.4 [allocator.adaptor.members]p1 as allocator_traits<decltype(OUTERMOST(x))>. However, OUTERMOST(x), as defined and used in this subclause, is an lvalue for which decltype produces an lvalue reference. That referenceness needs to be removed before the type can be used with allocator_traits.While we are here, the current wording for OUTERMOST uses the imprecise "if x does not have an outer_allocator() member function". What we meant to check is the validity of the expression x.outer_allocator(), not whether x has some (possibly ambiguous and/or inaccessible) member function named outer_allocator.
[2018-06 Rapperswil Thursday issues processing]
Status to Ready
[2018-11, Adopted in San Diego]
This wording is relative to N4750.
[Drafting note: The subclause only uses OUTERMOST_ALLOC_TRAITS(*this) and only in non-const member functions, so the result is also non-const. Thus, remove_reference_t is sufficient; there's no need to further remove cv-qualification. — end drafting note]
Modify 20.13.4 [allocator.adaptor.members]p1 as indicated:
-1- In the construct member functions, OUTERMOST(x) is
x if x does not have an outer_allocator() member function andOUTERMOST(x.outer_allocator()) otherwise; OUTERMOST_ALLOC_TRAITS(x) is allocator_traits<decltype(OUTERMOST(x))>. [Note: […] — end note]