On Mon, Dec 10, 2012 at 2:44 AM, Christopher Kohlhoff <chris@kohlhoff.com> 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