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

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-28 13:41:02

>> 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.
> 
> In that case, what is left of "boost-lite"?

The namespace bindings make up a small part of boost-lite, and as I
mentioned, I have been intending to delete them pending this review.
There are a wide range of generic algorithms and utilities built on top
of the C++ 14 STL, just like how Boost originally started life. A
reasonable cross selection of these generic algorithms are used by
Outcome and its unit test suite.

> Furthermore, can you describe what you mean by "std-flavoured form"?
> Does it mean that Outcome is hardwired to <system_error>, without
> support for Boost.System? Are there more differences?

std-flavoured form is the form presented for review. It uses no Boost
code. If std-flavoured form is accepted, I would permanently retire any
possibility of a boost-flavoured form by deleting the support code in
boost-lite.

>> 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.
> 
> "boost-lite" is not reviewed by Boost, and therefore not suitable for
> use in a Boost library, whether as submodule or something else. That is
> why I am suggesting an alternative.

Proposed Boost libraries with internal standalone libraries have been
reviewed and accepted into Boost in the past. I respectfully suggest
that people are turning a molehill into a mountain just because git
submodules hurt their heads somehow. This stuff is not important, it's
just dots on i's and crosses on t's stuff. Plumbing.

>> 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).
> 
> You may not get approval until this is resolved.

I see no point in making concrete statements about how I would lay
piping and plumbing. Lots depends on things I don't know answers to yet
because the relevant people haven't given me decisions yet, and they
won't make those decisions until they know if Outcome is entering Boost
or not.

For example, if the relevant people don't want Outcome's unit tests to
run as part of Boost release testing, then I could give you a very easy
answer on plumbing right now. But if they wanted all of the unit testing
to run, they would need to accept nearly all of the contents of
boost-lite as necessary because Boost.Test won't work with C++
exceptions disabled, and boost-lite's unit test suite uses most of
boost-lite's code. So whilst Outcome could be adapted to not use
boost-lite, its complete test suite cannot. And that is but one of many
decisions to be made by others which is out my control.

If the lack of detail on unimportant implementation plumbing is what
causes a rejection, then I would find that very unfortunate and short
sighted, especially as plumbing does not affect the end user experience.
That detail concerns the maintainers, and mostly me, only.

Niall

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