Boost logo

Boost :

Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-05-19 11:36:21

On 5/19/16 2:17 AM, Niall Douglas wrote:
> On 17 May 2016 at 19:39, Edward Diener wrote:
>>> But I'll freely admit I have given up on trying to make any
>>> substantial changes to Boost. I prototyped as I said I would a
>>> Boost-lite transition layer suitable for a clean Boost fork which I'm
>>> using in all my own code. Nobody was interested.
>> Maybe no one was interested because no one knows what you are talking about.
> This I think is inaccurate except maybe for your good self
> personally.
> I presented a plan for how to technically transition to a C++ 14 only
> Boost 2.0 at my C++ Now 2015 presentation:
> The talk was well attended, and by much of the more senior Boost
> community members.

I happened to attend that talk. I'm not sure if I understood it all.
But I can definitely say that I found the proposition unconvincing.

> I got the impression everyone understood well what was being
> proposed. Understanding was not the issue. Agreement with forking
> Boost into a C++ 14 only edition was the issue.

I saw nothing to be gained by this. I still don't. Boost as from day
one had the policy that any library submitted should be compatible with
the latest C++ standard. Any library author is free to build his library
with C++14 only.

Given the above, I never understood what you're proposal was (actually
is, because I still don't understand it). Was in some sense to
deprecate libraries which supported older compilers as well as later
ones? How would you enforce this? Was it to remove libraries which
support older compilers from the official distribution? What would be
the point of that if they still support the most recent version of C++?
Was it to fork boost and make C++14 only versions of the current
library? Why would making a libraries applicability narrower make
anything better? And who would that considerable amount of work? The
library author/maintainer? How would for him to do this? As I said the
proposal was either not well conceived, not well explained or most
likely both.

Now if you had proposed something like: I'd like to make and distribute
my own boost distribution which includes only those libraries which are
C++14 compatible but not compatible with older compilers - you don't
need anyone's permission. Just have at at it. It's not a huge task -
at least compared to the other tasks we do. Basically it's just means
making specialized version of some python script and start advertising.

Actually I alluded to some of this during my Boost 2.0 proposals in
2015. My concern was accommodating was addressing the expected future
growth of boost. Here are the relevant proposals

a) Resolve issues related to modularization and dependency management.
Work on this has been on going and making progress but it's slow going
as it's a much more difficult proplem than meets the eye.

b) Support development of the ability to generate, test and support
subsets of the Boost distribution.

c) NOW you could easily propose a subset distribution. Here are some ideas

i) a distribution which would not include any components which are now
supported by the standard library. This would work for those shops
which want to pick a canonical implementation and not have multiple
versions of the same thing.

ii) The Naill distribution - this would include only those libraries
which meet the Naill standard for C++14+ purity. It sounds to me that
this is what you're proposing. As more and more library authors became
convinced of the utility and popularity of restriction their library set
to those certified as "Naill pure" and made changes accordingly, this
distribution would naturally grow over time. It wouldn't take a lot of
work to maintained.

iii) Boost recommended distributation - the concensus of what we think
most programmers should be using and excluding those things that
wouldn't be recommended for new projects.

iv) The whole enchilada - what we are generating and testing now - which
would not change.

>>> The community
>>> *likes* things just the way they are: serving the Boost community,
>>> and to hell with the entire C++ community.

I don't think that is anyway accurate characterization of the community
- particularly those who have written, maintained libraries and/or
infrastructure. I also don't think there is any evidence to support
such a characterization. You seem to believe that the lack of support
for your proposal supports this characterization. Well, it's also
possible that the large majority of those exposed to the proposal just
considered it a bad idea.

>> Boost consists of about 130 different libraries. I venture to guess that
>> there is not a single library author of those 130 different libraries
>> that wouldn't like to see his library used more by the C++ community.

Right - obviously.

>> But why you think that Boost library authors write only for other Boost
>> library authors rather than for any C++ programmer is something you need
>> to explain in specific terms. Just making that claim does not explain
>> anything.


> The C++ 14 only libraries contributed to date are clearly written
> first for C++ not Boost.

No problem with that - actually, all the libraries have been written for

> They are the future we should be proactively
> encouraging into a new clean ground up redesigned fork of Boost, a

This doesn't follow from any premise so far stated. Such a fork is a
very, very, very bad idea as I stated above. It's also unnecessary to
achieve what I think you're goals are. (I doubt I share you're goals
either - but it doesn't matter. I challange you to implement as I've
described above and prove me wrong).

> Boost 2.0, instead of corralling them into legacy and outdated
> packaging, build, design, documentation and idioms out of some
> misguided desire for serving the legacy Boost usership before that of
> the wider C++ community.

I don't see this as a coherent view. But it doesn't matter. I believe
that the path we're on can lead to the ability to create custom
distributions with different focuses. I don't see any conflict. The
problem is that creating this "modular boost distribution system" is
much much harder than most people realize. The number of people who are
willing to suggest how to change something far, far exceeds the number
of people willing and able to actually make this happen.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at