On Tue, Mar 24, 2020 at 11:01 AM Mike via Boost
Can't speak for John, but personally I think that deciding for each header individually whether it might use c++11 features in a year doesn't make sense. In turn that would mean that everytime you want to use a c++11 feature in a header that didn't use one before, you need to wait for another year and you have to be super careful about which header includes which other header. Thats just a waste of time. Either deprecate c++03 for the whole library or not at all.
Boost libraries jump thru a tremendous number of hoops -- see the macro list in boost.config. For many things it's not to bad to support different configurations, although that's increasingly difficult. Obviously something in math makes them ready to move on from 03, but probably not for the functions here. John, who is responsible in part for config will certainly know. I guess the odd part for me is gcc and other clang compilers in 98 mode don't have the warning -- so there must be something unique about 3.x. And sure, I might jump on the band wagon to dump support for 98/03 in some future release. And, overall I'd like to reduce those dependencies anyway and newer standard libraries have facilities to help on that. That aside, what is the harm in simply defining the supression macro when
compiling your tests with older compilers? I think the bigger question is: Will date_time continue to support c++03 when (some) of the libraries it currently depends on don't?
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.