Andrey Semashev
I think BOOST_HAS_SYMBOLS_IN_STD_NAMESPACE, as you described it, would be mostly useless in the modern C++. libc++ already uses inline namespace and I suspect libstdc++ with gcc 5+ is also using some namespace versioning (I didn't check though). So most of the time the macro won't be defined.
Then if a library author is willing to support STL implementations with namespace versioning he will have to act despite that BOOST_HAS_SYMBOLS_IN_STD_NAMESPACE is not defined and still rely on STL-specific macros to detect the implementation. This is no better
As soon as it happens, some Boost code here and there will break and need to be changed, since libc++ is currently the only stdlib out of the 10 supported ones that do it, and is special-cased in various places. than
what is done currently.
I agree that a better solution would be a standard forwarding library. boost/detail/container_fwd.hpp and other libraries could then be
The point of the feature macro would be to make it slightly easier on the library developer, which will not have to enumerate all library implementations that support forward-declaring things in the std namespace, namely: - libstdc++ up to a certain version - stlport - Comeau - Roguewave - SGI - Metrowerks - VACPP - Modena - Dinkumware Any other library would either have to be special cased or to include headers directly. While this is a hack and not a defect, it's supported by 90% of the supported libraries, so having a feature macro makes sense to me. I think it should be a BOOST_HAS_, rather than a BOOST_NO_, since it's not a defect, but a "feature". ported
to it. This library then could fall back to including the STL headers and have the equivalent of BOOST_DETAIL_NO_CONTAINER_FWD.
If this is too much of a work for you then I think it's better to maintain the status quo, i.e. patch the affected places to include awareness of the BSL.
This can be done in the longer term, but I think a feature macro is an easier way to solve the problem in the short term.