Boost logo

Boost :

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-27 16:08:49


Niall Douglas wrote:

> Some Boost developers are ideologically and irrationally attached to "how
> things are done around here", yes.

Saying that is a good indicator that you simply don't understand the
objections, so you label them irrational.

Take for example the preprocessed outcome_v1_0.hpp header. You think that
the objection is that it's preprocessed. Not in the slightest.

The objection is that the non-preprocessed form, which is more convenient
when one needs to look at the implementation, study how it's organized, fix
a problem one's having (on mignw64, for instance), then prepare a pull
request, does not compile unless one has a foreign submodule installed,
which in turn picks up two more, even more foreign, submodules.

It's not possible to have foreign submodules in a Boost distribution, so the
choice there would be to either not provide the non-preprocessed form at
all, or provide it in a non-functional form.

In addition, having the preprocessed form automatically generated from
whatever's needed from boost-lite (1) obscures which specific parts of
boost-lite are used and (2) makes it possible for later versions to pick up
other parts of boost-lite.

The objection - no, the requirement for acceptance - here is not "do not
generate a preprocessed form of Outcome." The requirement is that everything
necessary for Outcome to compile and work in non-preprocessed form should be
part of the Outcome directory in $BOOST_ROOT/libs/outcome, without any
foreign repositories being incorporated there by reference.

That is, outcome.hpp in the Boost distro should compile and work in
non-preprocessed form.

This

- makes it possible to follow the implementation in non-obscured form,
- makes it immediately visible what Outcome's implementation detail
dependencies are,
- makes it possible for people to fix issues in Outcome and give you pull
requests against the input from which the preprocessed form is generated,
rather than patching the preprocessed header,
- avoids potential copyright/license issues with incorporating foreign
(non-boostorg) code via a script

> Actually there is overwhelming evidence that Boost **users** do not want a
> dependency on Boost. But I've been saying that for years now.

Yes, and I already answered it, with your swiftly proceeding to ignore my
answer. Probably because you didn't understand it, which of course means
it's irrational.

To repeat, it's not possible for a Boost user to not want a dependency on
Boost. A Boost user already has Boost. This is tautological.

Not wanting a dependency on "Boost" is characteristic for people who want to
use a specific Boost library without any of the rest. This is not the same
thing, and it does not at all describe all Boost users, so taking this
(existing and legitimate) subset and talking about them as Boost **users**
is simply disingenuous.

You might note that I'm not one who is a fan of intra-Boost dependencies.
You also might recall that I led an effort to eradicate many of the
unnecessary ones, have often expressed an opinion that Boost should move in
a direction of being less monolithic, and have done quite a bit of work to
that effect.

Nevertheless, things are what they are, and misrepresenting the actually
existing state of affairs does not do service to anyone. The fact remains
that (a) close integration between Boost libraries has its benefits to users
and (b) a substantial portion of Boost users are not bothered by the
downsides of this integration.

By all means make Outcome independent of any other Boost libraries -
depending on any isn't a requirement for acceptance, and many Boost
libraries do try to be reasonably self-contained (*) - but do recognize that
this move is not unquestionably without downsides.

(*) At one point in the past - the not very recent past - I had
shared_ptr.hpp compiling with an empty boost/config.hpp, because there was
significant demand from people to use it without anything else from Boost.
This demand subsided rapidly however once Boost took off. Nowadays, the
majority of Boost users do have Boost.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk