Re: The new Boost 17.0.0

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-12-02 09:03:25

> That's not what I have in mind. Macros don't solve the problem. What I 
> have in mind is that there is a single library that, in its interface, 
> can seamlessly take either boost::fs::path or std::fs::path, without 
> the user having to define anything.
>
> Of course, when building the library, you probably would need to have 
> Boost.Filesystem available.

This may work for simple types like string_view. But it won't work for 
(non-header-only) libraries using e.g. fs::path. At some point you have 
to convert to either type or to a third and that is gonna cost you

Additionally that interface may need includes to either or would require 
the user to include that first introducing an include-order issue.

And finally once you return a type you have no way for "either" (again 
except for simple types that could on-the-fly convert) and that too 
requires an explicit choice for the include.

IMO it would be enough on a cost-benefit ratio to go to C++11 by 
basically banning the use of MPL in Boost (the single-worst offender on 
compile times) and reducing the use of type_traits to the absolute 
minimum. Those 2 are (transitively) in the largest chunk of boost 
libraries and hence hit hard on compiletimes. Then using the std 
smart-pointers wherever possible would further untangle the libraries. 
So basically a bottom-up approach to improvement instead of a fork to 
whatever is the current greatest and latest. This could even be done 
for/by GSoC, interns or similar. And in ~8 years one can check if C++17 
would be a good base point.