Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
Hi Everyone,

The formal review of Niall Douglas' Outcome library starts today
(Fri-19-May) and continues until Sun-28-May.

Your participation is encouraged, as the proposed library is uncoupled and
focused, and reviewers don't need to be domain experts to appreciate the
potential usefulness of the library and to propose improvements.  Everyone
needs (and has suffered) error handling, and can compose an opinion on that
topic.

Outcome is a header-only C++14 library providing expressive and type-safe
ultra-lightweight error handling, suitable for low-latency code bases.

Key features:

*- Makes using std::error_code from C++11's <system_error> more convenient
and safe
*- Provides high-quality implementation of proposed std::expected<T,E> (on
C++20 standards track)
*- Good focus on low-latency (with tests and benchmarks)
*- Error-handling algorithmic composition with-or-without C++ exceptions
enabled
*- No dependencies (not even on Boost)

This review is timely, as C++17 brings us std::optional<T>.  The upcoming
std::expected<T,E> (an implementation provided in Outcome) is a
generalization of std::optional<T> that provides a <success|fail> value,
where the unhappy result is a 'std::error_code' or an instance of
"your-chosen-error-type".

The library further provides 'outcome<T,error-code,exception-ptr>' for
handling <success|error|exception> to safely wrap throwing APIs.

Documentation:
  https://ned14.github.io/boost.outcome/index.html

ACCU 2017 talk including design rationale:
  https://www.youtube.com/watch?v=XVofgKH-uu4

GitHub:
  https://github.com/ned14/boost.outcome

Latest tarball:
  https://github.com/ned14/boost.outcome/releases/download/
boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz

Note:  Tarball might be easiest; but if you want to clone from GitHub
directly, after the clone you should run the following command to get the
source zip exactly:  git submodule update --init --recursive

Please post your comments and review to the boost mailing list
(preferably), or privately to the Review Manager (to me ;-). Here are some
questions you might want to answer in your review:

- What is your evaluation of the design?

- What is your evaluation of the implementation?

- What is your evaluation of the documentation?

- What is your evaluation of the potential usefulness of the library?

- Did you try to use the library? With what compiler? Did you have any
problems?

- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

- Are you knowledgeable about the problem domain?

And most importantly:

- Do you think the library should be accepted as a Boost library?

For more information about Boost Formal Review Process, see:
http://www.boost.org/community/reviews.html

Thank you very much for your time and efforts.

--charley

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On Fri, May 19, 2017 at 6:43 AM, charleyb123 . via Boost
<[hidden email]> wrote:
> Outcome is a header-only C++14 library

Oops, are you sure about that? My understanding is that some of the
examples and tests are C++14 but the library itself is C++11 (maybe
earlier). Niall?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
>> Outcome is a header-only C++14 library
>
> Oops, are you sure about that? My understanding is that some of the
> examples and tests are C++14 but the library itself is C++11 (maybe
> earlier). Niall?

Outcome makes use of variable templates. There is still a code path
using types instead, but it is used exclusively on MSVC and I aim to
remove it as soon as Microsoft fix their compiler (I was told it'll be
VS2017 Update 1).

Outcome also makes heavy use of relaxed constexpr, but you're right it's
macroed out for VS2015. I intend to drop support for VS2015 before
Outcome enters Boost, if it is accepted, as VS2015 generates a lot of
code bloat when using Outcome which VS2017 does not. The MSVC specific
workarounds are also brittle and hacky, and I'd like them to go away and
use ISO C++ throughout.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On Fri, May 19, 2017 at 7:13 AM, Niall Douglas via Boost
<[hidden email]> wrote:
> Outcome makes use of variable templates. There is still a code path
> using types instead, but it is used exclusively on MSVC and I aim to
> remove it as soon as Microsoft fix their compiler (I was told it'll be
> VS2017 Update 1).

So Outcome requires C++14 then? Does this mean that compilation with
gcc 4.9.x is not supported?

> I intend to drop support for VS2015 before Outcome enters Boost,

Although I have not yet attempted my own implementation of
expected/outcome, it seems to me that an implementation using only
C++11, or even only pre-C++11, is quite possible. There are still many
shops that are "stuck" on particular older versions of Visual Studio.
Restricting a generally useful library which parallels a standard
library proposal, to only the latest version of Visual Studio sounds
quite harsh.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
>> Outcome makes use of variable templates. There is still a code path
>> using types instead, but it is used exclusively on MSVC and I aim to
>> remove it as soon as Microsoft fix their compiler (I was told it'll be
>> VS2017 Update 1).
>
> So Outcome requires C++14 then? Does this mean that compilation with
> gcc 4.9.x is not supported?

The minimum known working compilers are listed at
https://ned14.github.io/boost.outcome/prerequisites.html. As it says,
you need GCC 5.4 minimum, and in practice GCC 6 if you want to avoid
ICEs, and GCC 7 if you want full functionality (assuming GCC has fixed
the bugs Outcome triggers in GCC 6).

>> I intend to drop support for VS2015 before Outcome enters Boost,
>
> Although I have not yet attempted my own implementation of
> expected/outcome, it seems to me that an implementation using only
> C++11, or even only pre-C++11, is quite possible. There are still many
> shops that are "stuck" on particular older versions of Visual Studio.
> Restricting a generally useful library which parallels a standard
> library proposal, to only the latest version of Visual Studio sounds
> quite harsh.

A proposed Boost library need only conform to the latest C++ standard.
And as I hint at above, older compilers ICE a lot with Outcome. Use is
much more stable on the most recent POSIX compilers. No point therefore
in special casing Visual Studio, basically you need a compiler made last
year or newer.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On Fri, May 19, 2017 at 9:00 AM, Niall Douglas via Boost
<[hidden email]> wrote:

> The minimum known working compilers are listed at
> https://ned14.github.io/boost.outcome/prerequisites.html. As it says,
> you need GCC 5.4 minimum, and in practice GCC 6 if you want to avoid
> ICEs, and GCC 7 if you want full functionality (assuming GCC has fixed
> the bugs Outcome triggers in GCC 6).
> ...
> A proposed Boost library need only conform to the latest C++ standard.
> And as I hint at above, older compilers ICE a lot with Outcome. Use is
> much more stable on the most recent POSIX compilers. No point therefore
> in special casing Visual Studio, basically you need a compiler made last
> year or newer.

This means that out of the box, Beast cannot use Outcome, as Beast
requires only C++11. When I contemplate what an implementation of
expected/outcome might look like, I do not imagine anything that
requires more than C++11. Possibly even less than C++11.

When I look at the implementation of Boost.Outcome it seems needlessly
over-engineered. I cannot help but think that the Internal Compiler
Errors which result from attempting to build with earlier versions of
C++ are a consequence of this over-engineering and could have been
avoided with a more straightforward implementation.

While it is true the letter of the wording regarding Boost library
requirements do not mandate support for earlier compilers, I believe
it is in bad taste to use such wording to provide cover for
unnecessarily complex code. I feel that Outcome is sufficiently narrow
in scope and broad in utility that it should not be limited only to "a
compiler made last year or newer."

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On 5/19/17 9:18 AM, Vinnie Falco via Boost wrote:
> On Fri, May 19, 2017 at 9:00 AM, Niall Douglas via Boost

> While it is true the letter of the wording regarding Boost library
> requirements do not mandate support for earlier compilers, I believe
> it is in bad taste to use such wording to provide cover for
> unnecessarily complex code.

I don't think it's a great idea to make presumptions about motives here.

Boost has traditionally been willing to accept code which conforms to
only to the latest standard.  This has been a very good thing.  On the
other hand, library authors have a natural desire to see their code
widely used and have traditionally been desirous of maintaining backward
compatibility when reasonable to do so. This is one reason why most
widely used libraries support older compilers.  For niche libraries it
doesn't matter.  I don't think that this is an issue.


I feel that Outcome is sufficiently narrow
maybe you mean wide rather than narrow
> in scope and broad in utility that it should not be limited only to "a
> compiler made last year or newer."

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On Fri, May 19, 2017 at 10:35 AM, Robert Ramey via Boost
<[hidden email]> wrote:
>> I feel that Outcome is sufficiently narrow in scope
> maybe you mean wide rather than narrow

Yes, that's what I meant - thanks!

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, May 19, 2017 at 10:35 AM, Robert Ramey via Boost
<[hidden email]> wrote:
> I don't think it's a great idea to make presumptions about motives here.

You are right of course. My apologies.

Niall: Please explain why Outcome should not require only C+11.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 5/19/17 10:00, Niall Douglas via Boost wrote:

>>> Outcome makes use of variable templates. There is still a code path
>>> using types instead, but it is used exclusively on MSVC and I aim to
>>> remove it as soon as Microsoft fix their compiler (I was told it'll be
>>> VS2017 Update 1).
>>
>> So Outcome requires C++14 then? Does this mean that compilation with
>> gcc 4.9.x is not supported?
>
> The minimum known working compilers are listed at
> https://ned14.github.io/boost.outcome/prerequisites.html. As it says,
> you need GCC 5.4 minimum, and in practice GCC 6 if you want to avoid
> ICEs, and GCC 7 if you want full functionality (assuming GCC has fixed
> the bugs Outcome triggers in GCC 6).
>

Hi Niall - This is a bit confusing. It sounds like gcc 6 or greater is
needed. I can't think of a situation where ICE'ng the compiler is
considered working.

michael
--
Michael Caisse
Ciere Consulting
ciere.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> This means that out of the box, Beast cannot use Outcome, as Beast
> requires only C++11. When I contemplate what an implementation of
> expected/outcome might look like, I do not imagine anything that
> requires more than C++11. Possibly even less than C++11.
>
> When I look at the implementation of Boost.Outcome it seems needlessly
> over-engineered. I cannot help but think that the Internal Compiler
> Errors which result from attempting to build with earlier versions of
> C++ are a consequence of this over-engineering and could have been
> avoided with a more straightforward implementation.

You are very wrong on this.

There are toy Expected implementations like the many you'll find around
the web. Then there are STL quality implementations. They are
*significantly* more complex because of all the niche corner cases which
must be handled.

For example, Expected must work correctly both in constexpr and
non-constexpr, and any mix thereof. It must correctly propagate noexcept
to its member functions based on the T and E it is configured with. It
must inspect, with minimum compile time impact, T and E for what
constructors and operators it provides, and what the noexcept and
constexpr is on those, and again configure itself correctly as per the
LEWG proposal. It must correctly handle throwing copy and move
constructors and assignment, ensure that if T and E are trivially
destructible then so is the Expected, and all whilst ensuring that
nothing causes the optimiser to give up too early.

It is that stuff which ICEs older compilers. In particular, MSVC likes
to ICE on calculated noexcept. Older GCC likes to ICE on complex
variable template expressions. Older clang also has issues with using
variable template calculated values in default template parameters. The
list goes on.

You are probably right that a C++ 11 edition could be made. But it would
likely be a completely new codebase and without the two years of
maturation this code base has received.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall:

Over here I see a "boost-lite" submodule which exports public interfaces:
https://github.com/ned14/boost.outcome/tree/master/include/boost/outcome

But then in this README.md
https://github.com/ned14/boost-lite/blob/master/Readme.md

It says

"Herein is a set of tooling to enable a Boost library to swap in the
C++11 standard library instead of Boost..."

If Outcome requires C++14 (or maybe C++17?) what is the value of
including within Outcome a library which allows you to use C++11
standard library instead of boost? In other words, Outcome could
already be written against the C++ standard library facilities, since
they are guaranteed to be there in all versions of C++ which Outcome
supports.

I also see things in boost-lite like array, thread,
condition_variable, are those part of the public interfaces being
proposed?

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> The minimum known working compilers are listed at
>> https://ned14.github.io/boost.outcome/prerequisites.html. As it says,
>> you need GCC 5.4 minimum, and in practice GCC 6 if you want to avoid
>> ICEs, and GCC 7 if you want full functionality (assuming GCC has fixed
>> the bugs Outcome triggers in GCC 6).
>>
>
> Hi Niall - This is a bit confusing. It sounds like gcc 6 or greater is
> needed. I can't think of a situation where ICE'ng the compiler is
> considered working.

It depends on how you use Outcome in your code.

The compiler versions listed at
https://ned14.github.io/boost.outcome/prerequisites.html are where
Outcome passes all its unit tests clean. You can definitely write a lot
of code using Outcome which doesn't ICE the compiler.

However I also know from AFIO v2, which makes very extensive use of
Outcome, that it blows up older compilers in all sorts of fun ways. If I
took the time, I could rewrite how AFIO uses Outcome to not ICE the
older compilers. But given how alpha AFIO v2 is, it's just easier to
bump the compiler version needed for that library to a non-broken
compiler version.

That's my observation. I am not sure how to exactly document this
informal experience in Outcome's docs. After all, it's the compiler
vendors' fault, not Outcome's.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> If Outcome requires C++14 (or maybe C++17?) what is the value of
> including within Outcome a library which allows you to use C++11
> standard library instead of boost? In other words, Outcome could
> already be written against the C++ standard library facilities, since
> they are guaranteed to be there in all versions of C++ which Outcome
> supports.

boost-lite is no longer part of this review at all now that tribool
support has been dropped, but as you ask, boost-lite requires only C++
11 because lots of libraries beyond Outcome use it, including some C++
11 ones.

> I also see things in boost-lite like array, thread,
> condition_variable, are those part of the public interfaces being
> proposed?

Apart from boost_lite::tribool which has now been dropped due to review
feedback, nothing from boost-lite appears in the public interface.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On Fri, May 19, 2017 at 12:12 PM, Niall Douglas via Boost
<[hidden email]> wrote:
> Apart from boost_lite::tribool which has now been dropped due to review
> feedback, nothing from boost-lite appears in the public interface.

Is BOOST_OUTCOME_USE_BOOST_ERROR_CODE part of the public interface? I
see lines like this:
https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1.0/config.hpp#L190

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
What does Outcome have to do with Boost.Thread?
https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1.0/config.hpp#L63

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 19 May 2017 at 22:03, Vinnie Falco via Boost <[hidden email]>
wrote:

> Niall:
> ... what is the value of including within Outcome a library which allows
> you to use C++11
> standard library instead of boost?
>

C++11 should be banned (please, stop moving).

degski
--
"*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend,
Schmerzen aus Schwäche stillend.*" - Novalis 1798

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> The formal review of Niall Douglas' Outcome library starts today
> (Fri-19-May) and continues until Sun-28-May.

...

> GitHub:
>   https://github.com/ned14/boost.outcome

Before proceeding with the review, I'd like to request a clarification here.

In the event the library is accepted, what will the contents of the
repository boostorg/outcome be, and what will end up in the Boost release
under libs/outcome?

Stated differently, is the entire ned14/boost.outcome repo being submitted
as-is, or are some parts of it not part of the submission? Furthermore, are
the two Git submodules, doc/html and include/boost/outcome/boost-lite part
of the submission and if so, in what capacity, that is, are they expected to
remain Git submodules in boostorg/outcome, or are they expected to be copied
there from some fixed revision?

As I already asked, will boostorg/outcome be the primary source repository
for Boost.Outcome? If there is a PR submitted against boostorg/outcome, what
steps will need to be performed in order for that PR to become integrated
into the Outcome code base?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 19/05/2017 20:15, Vinnie Falco via Boost wrote:
> On Fri, May 19, 2017 at 12:12 PM, Niall Douglas via Boost
> <[hidden email]> wrote:
>> Apart from boost_lite::tribool which has now been dropped due to review
>> feedback, nothing from boost-lite appears in the public interface.
>
> Is BOOST_OUTCOME_USE_BOOST_ERROR_CODE part of the public interface? I
> see lines like this:
> https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1.0/config.hpp#L190

If reviewers make acceptance conditional on Outcome using Boost instead
of the C++ 11 STL for everything, then that configuration would be
activated and made permanent some how.

Note it hasn't been tested in well over a year, but it used to work once
and it could be resurrected without huge effort.

> What does Outcome have to do with Boost.Thread?
> https://github.com/ned14/boost.outcome/blob/master/include/boost/outcome/v1.0/config.hpp#L63

It's stale. I didn't want to invest the effort of removing it until the
review decides what form they want to accept Outcome in, if at all. You
may have noticed the large matrix of #if statements building an ABI
string, all that stuff takes lots of tedious effort to rejig.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> In the event the library is accepted, what will the contents of the
> repository boostorg/outcome be, and what will end up in the Boost
> release under libs/outcome?

That depends on what conditions the review manager places on acceptance,
if acceptance is recommended.

> Stated differently, is the entire ned14/boost.outcome repo being
> submitted as-is, or are some parts of it not part of the submission?

I am submitting it as-is in its present form. Reviewers may wish to
impose conditions regarding its boostorg form on acceptance.

> Furthermore, are the two Git submodules, doc/html and
> include/boost/outcome/boost-lite part of the submission and if so, in
> what capacity, that is, are they expected to remain Git submodules in
> boostorg/outcome, or are they expected to be copied there from some
> fixed revision?

The doc/html subrepo is simply the gh-pages branch used to deliver
Github Pages for the docs. Almost every recent Boost library submitted
does the same. If accepted, I'd do exactly whatever Boost.Hana did to
get its doxygen docs into boost.org.

As I've mentioned before, during build we assemble a single file include
of all the dependencies, including those parts of boost-lite needed.
There is therefore no strict need to ship boost-lite in any boostorg
repo, which is good as I believe boostorg currently doesn't support
project level subrepos.

But if that weren't acceptable, we could figure something out. To be
honest, I don't think it hugely important how we get Outcome into
boostorg, if accepted we'll figure out some solution which the build,
test and release managers are happy with and go with that.

Personally speaking, and reviewers can disagree if they want, what
matters is does the submitted library work well with Boost? I believe
the answer is that no collision, conflict nor bad interaction can happen
between any Boost code and any Outcome code. It therefore works well
with Boost.

Again, as I mentioned before, there is precedent here. When Hana was
submitted it didn't even use the STL let alone Boost. It also used cmake
and had no Boost.Build. Outcome follows exactly the path set by Hana.

> As I already asked, will boostorg/outcome be the primary source
> repository for Boost.Outcome? If there is a PR submitted against
> boostorg/outcome, what steps will need to be performed in order for that
> PR to become integrated into the Outcome code base?

I'd prefer not a script generated boostorg/outcome repo, it makes
maintenance harder. But if reviews impose conditions which require a
script generated repo as they did back in the day with ASIO, then I'll
make it work.

Niall

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123
Loading...