Re: [boost] Draft copy - Call for Submissions - CMake for Boost

Subject: Re: [boost] Draft copy - Call for Submissions - CMake for Boost
From: Miguel Ojeda (miguel.ojeda.sandonis_at_[hidden])
Date: 2018-10-21 05:33:39

On Fri, Oct 19, 2018 at 7:47 PM Robert Ramey via Boost
<boost_at_[hidden]> wrote:
>
> 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