Boost logo

Boost :

Subject: Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2018-01-15 18:00:34

On Mon, Jan 15, 2018 at 8:20 AM, Peter Dimov via Boost <
boost_at_[hidden]> wrote:

> > I should probably just add the relevant constexpr's to Boost.System.
> The only nontrivial change this entails is changing the member relational
> operators of error_category:
> class error_category
> {
> public:
> bool operator==(const error_category& rhs) const noexcept;
> bool operator!=(const error_category& rhs) const noexcept;
> bool operator<(const error_category& rhs) const noexcept;
> };
> into nonmembers:
> constexpr bool operator==(const error_category& lhs,
> const error_category& rhs) noexcept;
> constexpr bool operator!=(const error_category& lhs,
> const error_category& rhs) noexcept;
> bool operator<(const error_category& lhs,
> const error_category& rhs) noexcept;
> For the first two, g++ complained that members of a non-literal class
> can't be constexpr (whereas clang had no problem with it.) The third one I
> moved out for consistency.
> Nonmembers seem more idiomatic in either case; can someone think of an
> argument against having these out of the class?

Not to get into the weeds, but:

  (a) I don't care where relational operators are defined, but
  (b) Users should not be encouraged to override implementations of
relational operators themselves

The design should/does allow for "equality/equivalence" override for
user-custom domains, where that single (user-provided) implementation is
used by the relational operators, such as through:

  *- virtual bool std::error_category::equivalent(int, const
std::error_condition&) const noexcept;
  *- virtual bool std::error_category::equivalent(const
std::error_code&,int) const noexcept;

I realize you're talking about equivalence on the 'std::error_category'
itself, so std::-provided relational operators anywhere are fine (the user
should never override). If we (someday) wanted user-explicit override for
comparing 'std::error_category' instances, we should provide that single
function that the user can re-implement (which is then used by the
relational operators themselves). Thus, it seems that the relational
operators could go anywhere, and nobody should care.

(1) I want the 'constexpr'
(2) Its fine with me if relational operators are no longer member functions
of 'std::error_category'
(3) Ditto for 'std::error_code' and 'std::error_condition'
(4) I don't think users should provide custom implementations of relational
operators (customization is elsewhere)

If we were to venture "into the weeds", the question would become:

*- is comparison *exact-match* or *semantically-equivalent*? (i.e., are
two separate categories permitted to "compare-equal"?)

Possible rationalizations:

(1) Two separate 'std::error_category' instances may be semantically the
same category, but different instances (and "could' compare equal). This
would also "smooth-over" the singleton 'std::error_category' ODR issue.

(2) I've seen "enum-hierarchies" for error codes, where the
"subset-categories" actually merely represent subsets within the parent
category. Those sub-categories could compare equal to the parent-category,
because they literally represent windows into the same parent-category.

But of course, the current design is "identity" comparison for
'std::error_category'; and I want 'constexpr' more than I would want
semantic equivalence.

I have the opposite opinion for 'std::error_code', where I *always* want
semantic equivalence, and *never* exact-match testing (where the current
design tests for exact-match 'code==code' and semantic compare for


Boost list run by bdawes at, gregod at, cpdaniel at, john at