Title
bad_expected_access<void> member functions should be noexcept
Status
wp
Section
[expected.bad.void]
Submitter
Cassio Neri

Created on 2023-12-24.00:00:00 last changed 3 weeks ago

Messages

Date: 2024-04-02.10:29:12

Proposed resolution:

This wording is relative to N4971.

  1. Modify [expected.bad.void] as indicated:

    namespace std {
      template<>
      class bad_expected_access<void> : public exception {
      protected:
        bad_expected_access() noexcept;
        bad_expected_access(const bad_expected_access&) noexcept;
        bad_expected_access(bad_expected_access&&) noexcept;
        bad_expected_access& operator=(const bad_expected_access&) noexcept;
        bad_expected_access& operator=(bad_expected_access&&) noexcept;
        ~bad_expected_access();
      public:
        const char* what() const noexcept override;
      };
    }
    
Date: 2024-04-02.10:29:12

[ Tokyo 2024-03-23; Status changed: Voting → WP. ]

Date: 2024-03-15.00:00:00

[ 2024-03-12; Reflector poll ]

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

Date: 2023-12-24.00:00:00

According to [exception]/2:

Each standard library class T that derives from class exception has the following publicly accessible member functions, each of them having a non-throwing exception specification (14.5):

  1. (2.1) — default constructor (unless the class synopsis shows other constructors)

  2. (2.2) — copy constructor

  3. (2.3) — copy assignment operator

For good reasons, bad_expected_access<void> overrules from this general rule by protecting its special member functions. However, there's no reason these functions should not be noexcept.

History
Date User Action Args
2024-04-02 10:29:12adminsetmessages: + msg14042
2024-04-02 10:29:12adminsetstatus: voting -> wp
2024-03-18 09:32:04adminsetstatus: ready -> voting
2024-03-12 01:10:06adminsetmessages: + msg13997
2024-03-12 01:10:06adminsetstatus: new -> ready
2024-01-13 13:25:14adminsetmessages: + msg13906
2023-12-24 00:00:00admincreate