I am in favor of removing support for compilers that don't support partial specialization, partial ordering and void returns, notably MSVC 6.0/7.0.
For as little as my opinion may count, I would like to say that I strongly believe that hard-coding removal of support even for msvc-6 is wrong. If half of Boost or all of Boost does not work, then we can just let half of Boost or all of Boost not work ! No extra work for anyone. Maybe there are people out there using it and not reading this list. Maybe there are people who just irationally wish to use that compiler as I (apparently irationally) wish to use CodeGear's XE5 2 GB-download 6-GB installed size 1 hour-install made-in-2013-but-buggy-as-in-1998 2-or-3-or-4-times-faster-than-msvc-now-beat-that compiler. For it is written: "Thou shall love thy compiler.".
I wonder however how this should be done. Just removing the macro definitions from the config compiler headers is not enough because people can in principle use their own configs. Might it perhaps be better to leave
the compiler headers intact and just warn/#error in suffix.hpp when an unsupported macro is set?
I would like to kindly ask whether it is possible to define a (new) pre-processor symbol: BOOST_UNSUPPORTED_COMPILER and in a single new unsupported_compiler.hpp file (perhaps included by e.g. suffix.hpp => included by every file)... ... issue a warning message, an error message or a congratulation message based upon the new symbol. I am estimating that this might please everyone who wishes to see the "old" compilers failing every single library and also everyone who wishes to easily remove the hardcoded failure and still work with up-to-date Boost code (in order to drive themselves mad, if that is the desire of their hearts). Anyway, thank you ! (-: