Title
Container adaptor's `empty`/`size` should be `noexcept`
Status
new
Section
[queue.defn] [priqueue.overview] [stack.defn]
Submitter
Hewill Kang

Created on 2025-09-09.00:00:00 last changed yesterday

Messages

Date: 2025-09-16.15:26:31

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(); }
        […]
      };
      […]
    }
    
Date: 2025-09-09.00:00:00

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.

History
Date User Action Args
2025-09-16 15:26:31adminsetmessages: + msg15059
2025-09-09 00:00:00admincreate