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