Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-20 21:58:07

> I still don't understand. Let me describe what I would like to see, and
> you'll tell me if you see things the same way.
> 
> What I'd prefer to see is, in boostorg/outcome:include/boost/outcome, in
> addition to the outcome_v1.0.hpp header as currently generated, an
> outcome.hpp file that includes the headers in v1.0, as it currently does
> when BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE is defined. I
> also would like this to work without boost-lite, pcpp, gsl-lite being
> present at all in the boostorg/outcome repo (or on the user's system).
> 
> Furthermore, when someone issues a pull request against
> boostorg/outcome:include/boost/outcome/v1.0/something.hpp, I'd like to
> see this pull request kicking off a travis build as we're now used to,
> with this travis build actually testing Outcome with the pull request
> applied.
> 
> Does this make sense?

I appreciate your wishes in the above. I should point out that Outcome
already is tested per commit by Travis and Appveyor, and it keeps a
history at CDash: http://my.cdash.org/index.php?project=Boost.Outcome

But it is very hard for me to be more concrete at the present time. Most
of the dependency of Outcome on boost-lite is soft, e.g.
BOOSTLITE_CONSTEXPR <=> BOOST_CXX14_CONSTEXPR, Boost-lite lightweight
unit test <=> Boost.Test and so on. But some, especially
error_code_extended's use of boost-lite's ringbuffer_log is hard.

If reviewers want what I've done to achieve error_code_extended's static
storage removed entirely, that would remove much of the hard dependency
on boost-lite and a macro layer could rebind the boost-lite macros etc
to Boost ones. In this situation, boost-lite goes away in the boostorg
repo, otherwise the repos look identical.

If on the other hand people like the static storage, one would really
rather keep boost-lite in the Outcome repo because bug fixes to there
fix lots of other libraries too, and ringbuffer_log is very heavily used
by all my libraries. I being the person with the maintenance load here
will do whatever I think makes my life easiest. How the library is
internally organised I don't think a concern for the end user unless it
negatively affects them.

Similarly, if people like the cmake build with all the fancy stuff like
automatic C++ Modules, you need boost-lite in there for that. If
Boost.Build is felt sufficient, then you don't need it.

Again, I'd emphasise that boost-lite has no interaction with Boost or
any other code. It is a 100% ideal C++ 14 citizen, right down to ABI
permuting to ensure mixed versions do not collide. Nobody will ever need
to care it's there under the bonnet as an internal helper library.

And finally, I do intend to keep Outcome working completely independent
of Boost. The vast majority of my user base explicitly do not want a
Boost dependency. You'll have noticed the same with Hana.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/