Issue 3019: Presentation of "program defined classes derived from error_category" [syserr.errcat.derived] unclear and contains mistakes

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

Section: 19.5.3.4 [syserr.errcat.derived] Status: New Submitter: Thomas Köppe Opened: 2017-09-20 Last modified: 2017-11-09

Priority: 3

View all issues with New status.

Discussion:

The presentation of section [syserr.errcat.derived] is currently somewhat problematic:

It is not clear why this section exists and what it is specifying. Presumably, it is the subject of the phrase "in this subclause" of the sibling section [syserr.errcat.overview], but that's confusing (because this would require the interpretation of "this subclause" as the containing superclause). It would be an improvement to say "shall behave as specified in [syserr.errcat.derived]" in the introduction.
The current wording of [syserr.errcat.derived] requires that derived classes keep the name member function pure-virtual, making it impossible to have non-abstract derived classes. This appears to be an editorial error. Surely name should just not be required to be pure-virtual.
There seems to be no requirement concerning the message virtual member function.
We should use override rather than virtual.
I would welcome a short, introductory paragraph in [syserr.errcat.derived] that states (non-redundantly) that the following are requirements on users' derived classes.

Partial wording proposal:

In 19.5.3.1 [syserr.errcat.overview] p1, change:

-1- The class error_category serves as a base class for types used to identify the source and encoding of a particular category of error code. Classes may be derived from error_category to support categories of errors in addition to those defined in this International Standard. Such classes shall behave as specified in ~~this subclause~~19.5.3.4 [syserr.errcat.derived]. [Note: error_category objects are passed by reference, and two such objects are equal if they have the same address. This means that applications using custom error_category types should create a single object of each such type. — end note]
In 19.5.3.4 [syserr.errcat.derived], change:
```
virtual const char* name() const noexcept override  = 0;
```
-1- Returns: A string naming the error category.
```
virtual error_condition default_error_condition(int ev) const noexcept override;
```
-2- Returns: An object of type error_condition that corresponds to ev.
```
virtual bool equivalent(int code, const error_condition& condition) const noexcept override;
```
-3- Returns: true if, for the category of error represented by *this, code is considered equivalent to condition; otherwise, false.
```
virtual bool equivalent(const error_code& code, int condition) const noexcept override;
```
-4- Returns: true if, for the category of error represented by *this, code is considered equivalent to condition; otherwise, false.

[2017-11 Albuquerque Wednesday night issues processing]

Priority set to 3.

Jonathan to talk to Chris K and Walter about writing a paper describing the use of error_code, error_condition and defining your own.

Proposed resolution: