On Fri, Oct 19, 2018 at 7:47 PM Robert Ramey via Boost
As I've said - it's an idea and I'm glad it's being discussed.
For some time I've been concerned about the future of Boost as an organization. This is one idea - I'm curious about others. Here ate the concerns I have:
Maybe this could be another thread, but I am replying here for the moment.
a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be.
I would say the same as always, no? i.e. to provide a set of useful libraries on top of C++. Now simply there are several sets depending on whether you are targeting C++03, 11, 14... However, I do see your point: many of the "killer libraries" of Boost are now part of the standard, so the value of integrating Boost for many projects is much lower (even zero or negative) than with C++03.
b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost outside of the development of the C++. A example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost.
I guess the committee is trying to adapt to modern times. Waiting for the chain Boost -> production projects -> Standard -> compiler's std lib -> production projects is way too long nowadays, compared to other languages, frameworks, etc.; specially since C++ does not have a package manager. While many projects do not need either a big standard library nor a package manager (and/or are very conservative on dependencies), it is also true that many other projects and audiences benefit from both (package manager and/or bigger standard library). Therefore, I guess the committee is trying to keep new developers learning C++ :-)
c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of features than it already is. It puts C++ on a slow train to oblivion.
Not sure. It depends on what and who you ask. For instance, I appreciate many of the additions to the standard library and the language that have been added up to C++17. However, some of the proposals (both language and library ones) could have had more time to iterate, indeed. In my view, that is fine, as long as the requirement of never deprecating/breaking old code is slightly relaxed to cope with the new speed that C++ has taken. Otherwise, as you say, we will end up in an impossible-to-disentangle mess. To be honest, I am more afraid of the compiler-side, actually. There are still many missing pieces in the major compilers, specially library-wise, which makes many features basically unusable yet if you want to remain portable. Again, the side of the chain Standard -> compiler's std lib -> production projects is way too long. Compilers are still playing catch-up with published standards, so publishing prototypes and TSs does not help as much as it could.
This is not usual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organization, universities - etc.
All one has to do to see this is look at the papers list for the san diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users.
Indeed. I only hope people do not put all the proposals in the same bag! :-( There are some proposals that I see more as "experimental" or even changing the way we write C++ (as Bjarne warns) and others that are about the "established practice". For instance (and forgive me for the "spam"), my two small proposals "std::unique_val" and "std::secure_val" are similar, yet different in that sense. std::secure_clear and std::unique_val are pretty much "established practice"; while std::secure_val can be considered "experimental" (even if researchers are working on doing compiler work on something similar). Now, when I saw the list of proposals, I felt guilty for sending my two small ones adding to the noise; but really, I do believe adding such simple kind of stuff is a plus for C++ users. The ranges proposal, that is a bit not-too-simple for my taste, but...
Of course the C++ committee won't address the situation. Committees don't do that. Oh - now they want to expand scope again to include tooling. Wake up and smell the coffee people.
d) Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.
I am not sure I follow from c) to d). In other words, while the committee may not be addressing the situation (I don't know), I am not sure how Boost solves that, specially since most of the risky/controversial proposals are the language feature ones, which Boost cannot (typically) provide establish practice for. What do you mean? Cheers, Miguel