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

Subject: Re: [boost] [system] Add noexcept to conform with C++11
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-12-10 07:57:22

On Mon, Dec 10, 2012 at 2:44 AM, Christopher Kohlhoff
<chris_at_[hidden]> wrote:
> 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:

That's also my understanding, but I've never actually tried it with a
real C++11 compiler.

> - 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.

So after removal the BOOST_SYSTEM_NOEXCEPT define would look like this:?

   #ifndef BOOST_SYSTEM_NOEXCEPT
   #  define BOOST_SYSTEM_NOEXCEPT BOOST_NOEXCEPT
   #endif

> 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.

Vicente, this sound good to me, but:

* The change needs to include doc updates, and is generally complex
enough that I'd like to review a diff of your changes before you
commit them to trunk.

* The release notice needs to have a Boost.System entry notifying
users of the changes.

* We need to test the changes both with and without
BOOST_SYSTEM_NO_DEPRECATED to make sure they work as expected.

* We need to mark our personal calendars for, say, six months out to
be sure to make the BOOST_SYSTEM_NO_DEPRECATED change.

Marshall, once the end of the transition period reached, this approach
should address your concern about standards conformance if I
understand it correctly.

Chris,

Thanks for your help on this!

--Beman