Re: [boost] [system] Add noexcept to conform with C++11

Subject: Re: [boost] [system] Add noexcept to conform with C++11
From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2012-12-10 02:44:21

Hi Beman, Vicente,

On Mon, Dec 10, 2012, at 01:03 AM, Beman Dawes wrote:
> We need to contact Chris Kohlhoff to coordinate any asio changes with
> him. I have a vague recollection that he maintains the asio codebase
> elsewhere, so boost trunk is really just a mirror of some other repo.
> But I could be wrong about that.

Beman is correct. A change made to the boost tree only is liable to get
clobbered. Vicente, if you don't mind can you please raise a ticket so
that I can coordinate the changes to asio properly.

> That seems a lot worse than the noisy compiler error that will happen
> if user code just broke. How many folks are using a compiler that
> supports C++11 noexcept, have C++11 turned on, and are deriving from
> boost::system_error? Or am I missing other cases where user code would
> break?

The main problem is that this change breaks user-defined error
categories. These definitely exist in the wild, some in projects that
use C++11. These uses are currently perfectly valid.

If I understand correctly, a virtual function on a derived class is
permitted to have a more restrictive exception specification than that
on the base class. This should permit the following approach, which may
be more gentle on users:

- Document the non-noexcept forms in boost.system as deprecated.

- Define BOOST_SYSTEM_NOEXCEPT in terms of BOOST_SYSTEM_NO_DEPRECATED:

  #ifndef BOOST_SYSTEM_NOEXCEPT
  # ifdef BOOST_SYSTEM_NO_DEPRECATED
  #  define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT
  # else
  #  define BOOST_SYSTEM_NOEXCEPT
  # endif
  #endif

- Exclusively use the BOOST_SYSTEM_NOEXCEPT define in boost.system.

- Use the non-conditional BOOST_NOEXCEPT on error_category-derived
classes elsewhere in boost. This is ok because BOOST_NOEXCEPT will
always be the same as or a more restrictive than BOOST_SYSTEM_NOEXCEPT.

- After a couple of releases remove the test for
BOOST_SYSTEM_NO_DEPRECATED in defining BOOST_SYSTEM_NOEXCEPT.

This means that:

- User code is not immediately broken. The usual process of deprecation
grants them a transitional period. (If some users choose to ignore the
deprecation notice then that's their problem.)

- Users may define BOOST_SYSTEM_NO_DEPRECATED to ensure that their code
is forwardly compatible.

I would certainly prefer something like this over immediate breakage.

Cheers,
Chris