WG21 now says new library types must ship a pmr alias

A recurring worry about std::pmr is that it was a C++17 experiment the committee has quietly moved on from. The opposite is happening. In 2024 WG21 adopted a policy that points the other way: std::pmr is becoming the default allocation vehicle for new standard types.

That policy is P3002, “Policies for Using Allocators in New Library Classes.” It says new memory-allocating standard-library types should be allocator-aware, default to std::allocator, and ship a std::pmr alias backed by polymorphic_allocator. In other words, every future allocating container arrives with a pmr form built in, the way pmr::vector and pmr::string already do.

Two concrete papers follow from it. P3153 makes optional allocator-aware, pulling pmr into a core vocabulary type. And P1083, targeting C++26, standardizes resource_adaptor: a wrapper that turns any classic C++ allocator into a memory_resource, so the old compile-time allocator model and the runtime pmr model can meet. Here is that bridge, hand-rolled in a few lines to show the shape, driving a pmr::vector from a classic allocator:

The classic allocator logs each request; the pmr::vector on top never knows it is talking to anything unusual. resource_adaptor is exactly this, standardized, with the alignment and rebinding details handled for you.

What the trail of fixes says

The other signal is maintenance. The committee has kept filing and resolving defects against pmr for years: LWG 2969 fixed how polymorphic_allocator::construct passes allocators, LWG 3037 let pmr containers hold incomplete types, and a run of issues tightened alignment and size handling. Features that are being abandoned do not get that kind of steady attention.

pmr is not the whole allocator story, and it never tried to be. The compile-time Allocator model still exists for zero-overhead, statically-selected cases. What pmr offers is the runtime half: choose the strategy at run time, pass it across an ABI boundary, and reuse one arena across containers that share nothing but a pointer. The direction of travel in the standard is toward more of that. Eight episodes in, the through-line is simple: one small interface, the memory_resource from episode 1, chosen at runtime, that the rest of the library is quietly being built to honor.

Sources: P3002: policies for using allocators · P1083: resource_adaptor (C++26) · P3153: allocator-aware optional.