On 15.03.21 22:37, Emil Dotchevski via Boost wrote:
The committee seems to be concerned more with internal and external politics than with serving the community. If that wasn't true there would be ZERO library additions that haven't been battle hardened by being deployed and established themselves as the defacto standard already.
That's just bullshit. Right or wrong, good or bad, there are plenty of reasons for pushing for a library addition without waiting for a third-party library to establish itself as a de facto standard that have nothing to do with politics. For example: - There is a profusion of different libraries solving this problem, none of them individually popular enough individually to become a de facto standard. These libraries cannot talk to each other, splintering the community. - To proactively prevent the situation outlined above before it happens. - There is a clear need for a library, but the community has not yet produced such a library. - There is a clear need for a library, but the community /cannot/ produce such a library because it requires compiler support. Even if you think that all of these reasons are bad reasons, you should still acknowledge that they may have good intentions behind them and that they are not necessarily politically motivated.
The only thing they should be doing is rubber-stamping libraries that are already the standard for doing something. Instead, it's like a giant tube for force feeding us what we don't want (or else we would have adopted it already). For our own good of course.
If a library is already an established de facto standard, then there's little point in adding it to the C++ Standard, and a good reason for not doing so: it splinters the community, which is the opposite of what a standard should do. Example: I use Boost.Filesystem. I like Boost.Filesystem. Then std::filesystem shows up. Now I have to choose between Boost.Filesystem and std::filesystem. Boost.Filesystem is probably ahead in terms of features, but std::filesystem is the standard. Regardless of which one I pick, I may run into problems interfacing with third-party libraries that use the other one. -- Rainer Deyke (rainerd@eldwood.com)