Boost logo

Boost :

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-28 12:10:21

>> I can see why you might think that organisation superior, and I did
>> start out with that design. In fact, boost-lite used to define the exact
>> same macros as Boost, precisely because of that organisation, the idea
>> was that boost-lite was a substitute for Boost.
> The standalone Outcome does not have to use its own namespace. It could
> retain the boost::outcome namespace. That way we can remove yet another
> dependency (the part of "boost-lite" previously known as APIBind.)

If Outcome is accepted in std-flavoured form, I already intend to delete
the namespace bindings code entirely. They have only hung around due to
this upcoming review.

> That gives us a clean separation where the Boost.Outcome repository is
> "untainted" by any foreign submodules, and the standalone Outcome
> repository is a Boost.Outcome without a Boost dependency.

There is no "taint" from the boost-lite submodule. It can be included
into any translation unit without ill effect. It is a good neighbour to
all other C++, including different versions of itself.

You may find a reply to Robert sent recently with a description of one
post-approval Boost integration strategy I might take (use boost-lite
submodule if checked out, else fall back onto hard Boost dependency).
But I consider all that process and packaging trivia. None of it is hard.


ned Productions Limited Consulting

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