Quoting Robert Ramey <ramey@rrsd.com>:
I have no idea what else this might break.
It will break people using throw_exception but throwing things not derived from std::exception. This was an implicit requirement anyway,
What is an "implicit requirement"? You mean that previous users of boost/throw_exception where remiss if they didn't derive from std::exception or if they didn't surround throw_exception with #if BOOST_NO_TYPEID. I like to think I'm a smart guy but I don't claim to be telepathic.
Why would you need to surround throw_exception with #if BOOST_NO_TYPEID? The template function works whether it is defined or not...
but users will have previously got away with it if they never actually exercised their code on a no-exceptions platform.
Hmmm - It looks to me that the previous code would work fine on a no-exeptions platform - all it did was call a user defined throw_exception function.
At the very least the fact that the declaration for that case in boost/throw_exception was throw_exception( std::exception ) was at least a hint that it was intended for use with classes deriving from std::exception. Admittedly the client could crack open the boost namespace and add another overload for their own exception type(s), and include that before boost/throw_exception.hpp. Perhaps this use case was not sufficiently thought about in prior discussions. For me though the benefits of enabling Boost.Exception functionality for all existing code that uses boost::throw_exception outweighs that cost.