Re: [boost] [outcome] non-interface-related concerns

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.