Proposed resolution:

This wording is relative to N3376.

1. Modify the class error_category synopsis, [syserr.errcat.overview] as indicated: [Drafting note: According to the general noexcept library guidelines destructors should not have any explicit exception specification. This destructor was overlooked during the paper analysis — end note]

   namespace std {
     class error_category {
     public:
       constexpr error_category() noexcept;
       virtual ~error_category() noexcept;
       error_category(const error_category&) = delete;
       error_category& operator=(const error_category&) = delete;
       virtual const char* name() const noexcept = 0;
       virtual error_condition default_error_condition(int ev) const noexcept;
       virtual bool equivalent(int code, const error_condition& condition) const noexcept;
       virtual bool equivalent(const error_code& code, int condition) const noexcept;
       virtual string message(int ev) const = 0;
       bool operator==(const error_category& rhs) const noexcept;
       bool operator!=(const error_category& rhs) const noexcept;
       bool operator<(const error_category& rhs) const noexcept;
     };
   }
   

2. Before [syserr.errcat.virtuals] p1 insert a new prototype description as indicated:

   virtual ~error_category();
   

   -?- Effects: Destroys an object of class error_category.

3. Before [syserr.errcat.nonvirtuals] p1 insert a new prototype description as indicated:

   constexpr error_category() noexcept;
   

   -?- Effects: Constructs an object of class error_category.

[ 2013-04-20 Bristol ]

[ 2012-10 Portland: move to Ready ]

The issue is real and the resolution looks good.

Are there similar issues elsewhere in this clause?

Potential to add constexpr to more constructors, but clearly a separable issue.

Should error_category have a default constructor?

If you look at the synopsis in [syserr.errcat.overview], it appears the answer is no. There is no default constructor declared and there is another constructor declared (which should inhibit a default constructor).

However in paragraph 1 of the same section, descriptive text says:

Classes may be derived from error_category to support categories of errors in addition to those defined in this International Standard.

How shall classes derived from error_category construct their base?

Jonathan Wakely: In N2066 error_category was default-constructible. That is still the case in N2241, because no other constructor is declared. Then later N2422 (issue 6) declares the copy constructor as deleted, but doesn't add a default constructor, causing it to be no longer default-constructible. That looks like an oversight to me, and I think there should be a public default constructor.

Daniel: A default-constructor indeed should be provided to allow user-derived classes as described by the standard. I suggest this one to be both noexcept and constexpr. The latter allows user-derived non-abstract classes to take advantage of the special constant initialization rule of [basic.start.init] p2 b2 for objects with static (or thread) storage duration in namespace scope. Note that a constexpr constructor is feasible here, even though there exists a non-trivial destructor and even though error_category is not a literal type (see std::mutex for a similar design choice).

In addition to that the proposed resolution fixes another minor glitch: According to [functions.within.classes] virtual destructors require a semantics description.

Alberto Ganesh Barbati: I would suggest to remove =default from the constructor instead. Please consider that defaulting a constructor or destructor may actually define them as deleted under certain conditions (see [class.ctor]/5 and [class.dtor]/5). Removing =default is easier than providing wording to ensures that such conditions do not occur.