On 16/12/2019 18:48, Peter Dimov via Boost wrote:
One of the big reasons I don't get Peter's caution is that anywhere I've ever worked, nobody has upgraded Boost more frequently than every two or three years, and it's usually a lot more. Maybe I've worked in the wrong places.
This might well be true in a corporate setting, but downstream packagers such as Linux distros, brew, vcpkg etc "upgrade" Boost more frequently (on each release) and every breaking change in Boost typically affects (many) other packages that then need to be fixed.
That's a good argument. I guess another reason I feel suspicious of "deprecation warning now, change default sometime later" is that in my experience people always forget to do the second step. Then you get libraries - there are a few popular old C++ ones I won't mention - which implement the deprecated interface forever. That makes compiling with them just a massive noise of deprecation warnings nobody acts upon. It's like all those codebases we've all used which spew warnings, and nobody ever fixes them. I think there's a compromise solution here: Make a new macro: BOOST_MACRO_DEFAULT_CHANGED(PHOENIX_LIMIT, BOOST_PHOENIX_LIMIT, 107200, 107600) This expands into something like: #if BOOST_VERSION >= version && defined(oldmacro) #error oldmacro was replaced with newmacro in Boost vXXX. Please use newmacro to avoid this error. #else #warning oldmacro was replaced with newmacro in Boost vXXX, and use of oldmacro will fail the build from Boost vYYY onwards. Defining newmacro to oldmacro until then. #define newmacro oldmacro #endif I'm not entirely sure how to wrap that into a macro which is portable, but you get the idea. Niall