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

3681. Further considerations on LWG 3679

Section: 20.4.1 [mem.res.syn], 20.2.2 [memory.syn] Status: New Submitter: Jiang An Opened: 2022-02-28 Last modified: 2022-05-17

Priority: 4

View all issues with New status.


The issue reflected in LWG 3679 is not limited to <ranges> and std::ranges::istream_view.


 #include <vector>
// some standard headers other than <memory> and <memory_resource>

template<class T> my_ator {/*definition, meeting the requirements of Cpp17Allocator*/};

int main()
  std::vector<int> v1; // Generally works. Is this guaranteed?
  std::pmr::vector<int> v2; // Usually fails to work on libstdc++. Is this intendedly permitted??
  std::vector<int, my_ator<int>> v3; // Generally works. Is this guaranteed?

Currently libstdc++ only provides forward declarations of std::pmr::polymorphic_allocator in headers of standard allocator-aware containers, which means that users are required to include both <memory_resource> and <vector> in order to create a std::pmr::vector<T> object. If libstdc++ is technically conforming here, one may say the definition of std::allocator is also not guaranteed to be available in these headers, so <memory> is required to be included together with such a header to make standard-container<T> work.

Furthermore, the specification of allocator-aware containers are heavily dependent on std::allocator_traits. If these containers are not guaranteed to work when the definition of std::allocator_traits is not available, and the definition of std::allocator_traits is not guaranteed to be provided in headers of these containers, then users are effectively always required to include <memory> in order to create a container object, even if they are using their own allocators.

[2022-05-17; Reflector poll]

Set priority to 4 after reflector poll.

Proposed resolution: