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

Subject: [boost] A possible date for dropping c++03 support
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-08-28 03:50:59

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 <glen.fernandes_at_[hidden]>
> Sent: Monday, August 27, 2018 11:17 PM
> To: boost_at_[hidden]
> 
> 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