John Maddock wrote:
Sorry but suggesting we just revert something back to a way it never actually was in the first place, after it's been functioning apparently OK for 4 years, and which users may well have been relying on over that time isn't going to wash.
lol - I guess the best arguement against my proposal would be to say that my proposal at this point (if that's what it was) would be engaging in the same practice that I've been arguing against in the first place. Which would be a tough argument to counter. It's sort of like eating my own tail. lol If this discussion prevents some future library author from gratuitously extending the dependencies of existing code, it will have been worthwhile. Still, I would like to consider one thing that might inprove things; a) boost::throw_exception would be deprecated. (not changed) b) the same facility would be invoked by: #include <boost/exception/throw_exception.hpp> ... boost::exception::throw_exception .... as usual, the deprecation would mean a) an initial period of compile time warning b) eventual elmination. This later stage would create a compile time error which would be trivial fixable. No program bugs would be introduced. This would advise programmers who've been inadvertantly including boost::exception that they are in fact doing so and give them the opportunity to decide whether or not they really want to do this. Of course this might require them to read at least some of the documentation of boost exception. This is not a bad thing. Authors of new code would conciously decide whether or not they were including boost exception. Also not a bad thing. Note that I'm not making any judgment on the merits of boost exception itself. This about limiting unintentional dependcies. Boost exception just happens to be the main example here. Robert Ramey