Proposed resolution:

This wording is relative to N5014.

1. Modify [queue.syn], header <queue> synopsis, as indicated:

   […]
   // [container.adaptors.format], formatter specialization for queue
   template<class charT, class T, formattable<charT> Container>
     struct formatter<queue<T, Container>, charT>;
     
   template<class T, class Container>
     constexpr bool enable_nonlocking_formatter_optimization<queue<T, Container>> = false;
   
   // [priority.queue], class template priority_queue
   template<class T, class Container = vector<T>,
            class Compare = less<typename Container::value_type>>
     class priority_queue;
   […]
   // [container.adaptors.format], formatter specialization for priority_queue
   template<class charT, class T, formattable<charT> Container, class Compare>
     struct formatter<priority_queue<T, Container, Compare>, charT>;
     
   template<class T, class Container, class Compare>
     constexpr bool enable_nonlocking_formatter_optimization<priority_queue<T, Container, Compare>> = false;
   […]
   

2. Modify [stack.syn], header <stack> synopsis, as indicated:

   […]
   
   // [container.adaptors.format], formatter specialization for stack
   template<class charT, class T, formattable<charT> Container>
     struct formatter<stack<T, Container>, charT>;
   
   template<class T, class Container>
     constexpr bool enable_nonlocking_formatter_optimization<stack<T, Container>> = false;
   
   […]
   

[ Kona 2025-11-08; Status changed: Voting → WP. ]

[ 2025-10-17; Reflector poll ]

Set status to Tentatively Ready after five votes in favour during reflector poll.

[ 2025-10-14; Reflector poll ]

Set priority to 2 after reflector poll.

This is a duplicate of LWG 4146, with a different proposed resolution.

As the standard currently defines formatters for `queue`, `prioriy_queue`, and `stack` `enable_nonlocking_formatter_optimization` is specialized to `true` for these adaptors per [format.formatter.spec] p3:

Unless specified otherwise, for each type `T` for which a formatter specialization is provided by the library, each of the headers provides the following specialization:

template<> inline constexpr bool enable_nonlocking_formatter_optimization<T> = true;

However, formatting an adaptor requires formatting of the underlying range in terms of `ranges::ref_view`, and we disable the nonlocking_optimizations for all ranges, including `ranges::ref_view`.

This problem does not occur for the `flat_set`, `flat_map` adaptors, which are also ranges, but unlike `stack` etc. they do not have a specialized formatter. They use the `formatter` specialization for ranges and we already disable the optimization for that formatter.

The proposed wording has recently been implemented in gcc's libstdc++.