[boost] A possible date for dropping c++03 support

Note: I accidentally sent this message only to glen at first and am now mirroring it to the boost-ml

-----Original Message----- From: Glen Fernandes Sent: Monday, August 27, 2018 11:17 PM To: boost@lists.boost.org

On Mon, Aug 27, 2018 at 10:56 AM Mike Dev wrote:

...

Currently, many libraries are committed to support c++03, meaning they won't just start to use c++11 features [unconditionally] without prior announcement and some transition phase. After officially dropping c++03 support (with prior announcement and appropriate transition phase), whether a library happens to still compile with c++03 or not becomes an implementation detail that might or might not change with every new revision.

Do you have an example of a Boost library author or maintainer that has refused (either a pull request, or a other feature request) to leverage C++11+ features (after detecting them with Boost.Config, of course) to provide some more optimal implementation in their library, or provide a new feature their library?

There are Boost libraries are committed to supporting C++03, but they also leverage C++11, C++14, C++17 features when available, because this is what those particular library authors/maintainers are happy to do. (Myself included: I would not refuse to take advantage of a C++17 feature for C++17 users, while still supporting C++11 for C++11 users).

Conditionally using a c++11/14/17 feature is (usually) not the problem although there are sometimes pitfalls as Peter mentioned. However, it also has limited utility. E.g. it doesn't make sense to simplify a function implementation using c++11 features like auto, range based for, decltype, constexpr instead of TMP, if you have to maintain the c++03 code path as well. In principle, you could conditionally get rid of some boost dependencies in c++11 mode, but again at the cost of maintaining two different code paths (as boost types often have slightly different semantics from c++11). So why do it? And you still can't deprecate the dependency itself because it is still needed in c++03 mode. So except for cases with a very high value proposition (move semantics, simplified api, c++11 only functionality) or simple annotations (noexcept, override) using c++11 features *conditionally* is usually not all that beneficial. My hope here is that at some point, those boost libraries will finally start to use c++11 features *unconditionally* in order to simplify things - not add even more complexity in the form of conditional compilation. Best Michael