Proposed resolution:

This wording is relative to N5014.

1. Modify [queue.defn] as indicated:

   namespace std {
     template<class T, class Container = deque<T>>
     class queue {
     public:
       […]
       constexpr bool              empty() const noexcept { return c.empty(); }
       constexpr size_type         size()  const noexcept { return c.size(); }
       […]
     };
     […]
   }
   

2. Modify [priqueue.overview] as indicated:

   namespace std {
     template<class T, class Container = vector<T>,
              class Compare = less<typename Container::value_type>>
     class priority_queue {
     public:
       […]
       constexpr bool            empty() const noexcept { return c.empty(); }
       constexpr size_type       size()  const noexcept { return c.size(); }
       […]
     };
     […]
   }
   

3. Modify [stack.defn] as indicated:

   namespace std {
     template<class T, class Container = deque<T>>
     class stack {
     public:
       […]
       constexpr bool              empty() const noexcept { return c.empty(); }
       constexpr size_type         size()  const noexcept { return c.size(); }
       […]
     };
     […]
   }
   

[ 2025-12-10 Status changed: Tentatively NAD → NAD. ]

[ 2025-10-22 Reflector poll. Status changed: New → Tentatively NAD. ]

General disagrement with the proposed change. Implicitly changing container requirements. We should fix `flat_` adaptors instead.

C++23 container adaptors flat_meow all have `noexcept` `size`/`empty` members.

However, the `size`/`empty` members of other container adaptors are not mark `noexcept`, even though they behave the same as flat_meow that returning the `size`/`empty` of the underlying container.

It makes sense to make them `noexcept` as well for consistency. Although the standard doesn't explicitly say those two members of the container must not throw, the fact that all standard containers and common third-party containers mark them as unconditionally `noexcept` implies that it's perfectly reasonable to assume that they never will.