[ 2022-05-17; Reflector poll ]

Set priority to 4 after reflector poll.

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

Example:

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