[boost] The future and present of Boost

Subject: [boost] The future and present of Boost
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-24 16:19:56

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Peter Dimov via Boost
> Sent: Wednesday, October 24, 2018 5:00 PM
> 
> Mike Dev wrote:
> 
> > - Unnecessary dependencies. All the projects I'm working on nowadays   are
> > c++14 or even 17. Why the hell does the latest version of my  preferred
> > boost library X still have a dependency on boost library Y that has been
> > merged into the standard since c++11 or been superseded by c++11 language
> > feature? It just adds complexity to the build process, increases compile
> > times and sometimes leads to subtle bugs. I'm paying (sometimes little
> > sometimes heavily) for something I don't use/need (c++98 compatibility).
> 
> We've been over this a few times already. We can't simultaneously support
> C++03 and C++14 (without heroics) because these are ABI- and
> API-incompatible. 
> 
> [...]
> 
> We can switch to std::function unconditionally, but only if we drop C++03
> (for some definition of C++03 because only the latest and greatest MSVC is
> ~fully C++11 compliant.)

That's my point: I don't want boost libraries to invest any more effort in 
maintaining c++03 support (I think I made that clear in the last ml-thread about 
this 2-3 month ago).
It either makes everything more complicated or it requires more dependencies
and/or - in the worst case - leads to compile and/or run-time overhead, because 
an efficient c++11 language construct is emulated with some wicket macro/TMP-library 
solution (which are even more wicket in c++03) or we have additional conversions 
between boost types and std types. At the very least, it requires more test-effort,
because you want to support the newer standards anyway.

Before someone puts up a strawman: Of course that doesn't necessarily mean you 
should remove boost::X from your code if it provides other benefits (other than 
backwards compatibility) over std::X. And no, I'm also not suggesting to just 
drop a useless c++11 feature into your code just out of malice (but realistically,
almost every c++03 boost library could either shed dependencies or improve
the code by using c++11 features/types).

I don't know what the majority of the boost user base needs and what your personal
needs (as a maintainer and most likely user of your own library) are but I'm 
saying that, while maintaining backwards compatibility is probably important for 
some users, the side effects of it drive others (such as me) away from boost. 
It is a tradeoff and I'm certainly not so arrogant to believe that dropping 
backwards compat would be a net win for boost, but for me personally it would 
make boost more attractive again.

Most other pieces of software can just bump their major version, when they think 
breaking backwards compat is beneficial, and the user can then either upgrade too 
or stick to the old version if he can't accommodate for the changes (yet). Often 
the old version still gets bugfix support for some time. 
But in boost the only way to create a v2 seems to be the introduction of a totally 
new library. I think that is at least one drawback of the common (non-modular) 
release model.

Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 
is full constexpr support and expressions sfinae and even MSVC2013 provides most 
of the library and language bits.
Any other conformance bugs (e.g. two-phase lookup) have to be dealt with anyway and 
are orthogonal to the c++03 / c++11 question.

Mike